A recent comment by Chris on my post about css vs tables, reminded me that developing cross-browser css still gives people trouble. Fortunately there’s an easy solution, which is to use a css reset file. However css resets have some cons along with the pros.
Here’s Chris’ comment:
One issue is that different browsers have different definitions of the padding and the margin variables. The fact that different browsers and different versions of browsers look at these and other variables differently is a really pain.
All true except for that last part about it being a pain to develop cross-browser css.
I want to talk about the problem of different presentational defaults used by browsers, and then talk about how css resets solve the problem and why you may not want to use a css reset.
The Problem of Browser Defaults
When you add an <h1> to a web page, but don’t specifically style it in any way, that <h1> will by default have some styles associated with it.
It will likely be larger than other text on the page, it will be bold, and it will have a certain amount of space above and below.
This is a good thing and one of the reasons html is relatively easy to use. An <h1> should look different from an <h2>, which should look different from a <blockquote>, etc. By default all these things will look different.
The problem is there isn’t a standard for what those defaults should be. While browsers with the same rendering engine will use the same defaults, two different rendering engines could have different default values.
The table below shows defaults for an <h1> tag in several browsers.
The values are from a more complete table of CSS2.1 User Agent Style Sheet Defaults. The date listed in the url shows the full table is nearly 2 years old, but there’s no reason to think the default values have changed.
Here’s a more recent table of defaults for IE6–IE9
| Browser | font-size | margin |
|---|---|---|
| W3C Recommended | 2em | 0.67em 0 |
| IE7 | 24pt | 14.25pt 0 |
| IE8 | 2em | 0.67em 0 |
| FF2 | 32px | 21.4667px 0 |
| FF3 | 32px | 21.4333px 0 |
| Opera | 32px | 21px 0 |
| Safari | 32px | 21px 0 |
Browsers typically use 16px as the default font-size for body text so 2em = 32px = 12pt, but it’s easy to realize how different these values will be if you change the font-size on the body or start setting the size for the <h1> tag.
Another common example of different browser defaults are lists. By default lists are usually indented, however one browser will do that by giving the list some margin and another does it by giving the list some padding.
When you come along and change one or the other things are no longer equivalent across browsers.
There are many other inconsistencies and if you aren’t aware of each it can be confusing to try to make your design work cross browser.
The Simple Solution
The solution to the problem above is actually quite simple. Since it’s the browser defaults causing the problem, don’t let the browser default be the style that’s applied.
If you explicitly set a margin-bottom of 20px on <h1> tags then all browsers will use that 20px. It’s only when you don’t explicitly set the style that the default will be used.
For example when I’m using an unordered list on a site, I’ll add the following to the css
{code=css}
ul {margin: 0; padding: 0}
{/code}
The line above will ensure that all browsers are now using the same margin and padding on ordered lists. The inconsistency is gone. Of course since I probably do want some indentation, I might change the above to something like
{code=css}
ul {margin: 20px; padding: 0}
{/code}
Now the list will be indented 20px as well as having 20px of space on the top, bottom, and right. More importantly all browsers will add those 20px as margin. You can just as easily place the 20px on the padding and leave the margin as 0 if you want. The important thing is to set both.
CSS Resets: Pros and Cons
As I mentioned above there are a lot of inconsistencies in browser defaults and you probably aren’t going to remember them all, let alone remember to explicitly set values for all of them. This is where css resets come in.
Pros
CSS resets set new and consistent default values for you. If we look at Eric Meyer’s css reset file (probably the most used of all css resets) it starts by listing a number of html elements and applying the following css to all of them.
{code=css}
margin: 0;
padding: 0;
border: 0;
font-size: 100%;
font: inherit;
vertical-align: baseline;
{/code}
There’s more to the file, but the idea is still to solve the problem of different browser defaults. If you use the css reset you can be sure that all the tags listed will have a margin of 0px, a padding of 0px, etc. The inconsistency has been removed.
The other popular css reset is the one provided by Yahoo and you can read a few thoughts about both here.
Sounds like a perfect and easy solution so where’s the downside?
Cons
The downside is that while the reset fixes the inconsistency problem, it does so by creating new defaults that you may or may not want. The new defaults will be consistent cross browser, but you’ll likely still end up wanting to style many of them.
Keeping with the example of lists, most people usually do want their lists to be indented. Odds are even with a reset in place you’ll still add those same 20px (or any value of your choosing) to the margin or padding.
You now have a bit of redundant code as you’re specifying the margin or padding style twice. Is that big deal? Not really. It’s a few extra characters in a css file, but it is a few extra characters that don’t need to be there for every element you later style. Those characters do add up.
Meyer himself says as much when he tells us
In other words, this is a starting point, not a self-contained black box of no-touchiness.
Most people, however, tend to treat resets as a black box.
Another potential issue is the tags you don’t style. For example one of the tags set to have 0 margin and padding is the <abbr> tag.
I don’t know about you, but I can’t remember the last time I used the <abbr> tag. Because I don’t use the tag regularly, I generally don’t style it.
Imagine though at a later time I or a client decides to use the tag. With the reset there will be no margin or padding on the abbreviation, which is probably not what you want. In this case letting the browser set the default might be the better option.
This isn’t exactly a difficult problem to overcome. You just have to make sure every element listed in the reset is styled the way you want, whether it’s your own style, the reset style, or the browser default style.
Like Eric Meyer says a css reset is a starting point and not a black box.
Should You Use a CSS Reset?
Using a css reset is really up to you. They will fix the problem of browser defaults. They also create a few minor issues of their own, that quite honestly either aren’t a big deal or may never even come up.
I usually don’t add one (though I do use one at times), mainly because I am already styling those elements where there’s probably going to be a cross-browser default conflict. After coding for a number of years I’ve developed my own way of structuring a site and know where the potential issues are.
With tags I don’t commonly use or style, I’d rather let the browser default take over, since it generally won’t break the design and there isn’t any reason everything needs to look exactly the same across all browsers.
I take care of the elements I know can cause major issues and tend not to worry about those with minor differences.
That’s not to say I’ll never use a reset or that you shouldn’t use one either. As long as you understand what they’re doing they’re great files. Just treat them as a starting point and don’t simply add one and forget about it.
Ideally you would use one or two css resets as a guide to build your own reset file that you can use in your projects based on your style of coding and design.
Summary
Cross-browser inconsistencies often trip up new css developers. The fix is really quite simple in that you just need to set explicit styles as opposed to relying on browser defaults. For many of us that will only mean adding the styles to a few key elements, though it depends on how you typically structure a site’s html.
CSS resets solve the problem quickly and easily by declaring all those styles for you including a variety of elements you may not remember to include on your own.
If you’re new to css or find you have trouble developing a design that looks the same across browsers you probably want to use one.
On the other hand if you’re an experienced developer who doesn’t have cross-browser issues you may not need to add a reset (unless a reset is the reason for your cross-browser consistency) or you should remember not to treat your reset as a black box.
The choice is really yours. I do think css resets are a good thing as long as you understand what it is they’re doing and where the few potential problems with them are.
Out of curiosity do you use a css reset? If so which one and do you just include it or do you use it at as a starting point?
Download a free sample from my book, Design Fundamentals.
I’m with you here. People tend to use CSS Resets as a magic blackbox and forget about it. I don’t use them because I style every element I’m placing on the page, and by not using one at least I can be sure that any other element will have some default style (which is better than no style).
And I think it’s really the black box thing that’s the problem. There’s nothing wrong with css resets per se and I think they can help some people a lot. It’s more just placing them in your code without thinking about what they’re doing that ends up being the problem.
I’ve used a reset for a little while now after getting tripped up by browser defaults before. The table of defaults above makes me think there should be a reset that sets all tags to the W3C recommendation, rather than to zero. That way, unused tags like th tag mentioned above would get a sensible styling even if the developer never specifies what it should be (outside of the reset).
Ideally there would be one accepted standard and all browsers would follow it. I’m not going to hold my breath waiting for that to happen though. 🙂
A CSS stylesheet is like a blank canvas. Without one, it’s painting on a canvas that already has paint splatters all over it.
A lot of times, those who don’t use resets create one as part of their normal CSS file because it looks inconsistent across browsers. Or people start including separate stylesheets for IE, using the !important tag to target different browsers, or sissying out and saying “I don’t support that browser.”
I’ve found my use for those “methods” are 99% unnecessary when using a reset stylesheet. I’d much rather paint what I want and not work with someone else’s mess.
I like the painting analogy.
Why not use just the necessary minimum for reseting some browser conflicts? I made CSS Mini Reset http://www.vcarrer.com/2010/05/css-mini-reset.html that does exactly that.
Again nothing against using css resets. While I don’t always use them I have and will again. I mostly want people to understand what they’re doing so that they don’t treat them as a black box.
By the way your mini-reset definitely helps solve some of the problems with the longer resets. I’d be more inclined to use it.
I think what ultimately works best is to look over the resets out there and modify them to suit your own coding styles.
Good one, Vladimir! My “reset” ends up looking a lot like yours. I’ve started with various resets (YUI most recently), and any time I explicitly style an element, it gets removed from the “generic” reset. Then I get rid of any elements that aren’t part of the design.
Guess what I’m left with? Something that looks an awful lot like the mini-reset. 😉 Copying yours would take the ‘reversing’ out of the process.
And the key is you aren’t treating the resets as a black box and so they work for you. Looking over Vladimir’s reset I think I would end up being left with something similar as well. I might change a few things, but I think I’d be left with something very similar.
its a bad thing with the iE7
Hey Ian, that´s actually a great idea, does anyone know if there is a W3C preset around anywhere? They should really put one out.
If you click through to the table I linked to in the post it’ll show W3C recommended defaults. You should be able to build a reset from those.
Steven and Greg unfortunately there is no magic solution for CSS Resets, important thing like Steven sad is that you shouldn’t use CSS Reset like black closed box. Be aware what that CSS does.
There times that I don’t use CSS Reset or use Eric Meyer’s Reset or make some personalized CSS Reset.
True. I think the most important thing is to understand what the css reset is doing and then you can use any as a starting point. I like your mini-reset because it doesn’t try to be all inclusive. At the same time I like Eric Meyer’s reset because it does try to be all-inclusive. Depends on the project in front of me and the needs of that project.
I don’t use any CSS reset which sets every property to zero value, mainly because every new addition to the content (HTML) requires writing CSS if it was not previously used.
Every my projects uses the same HTML building blocks, it has this CSS file http://onxshop.com/share/css/default/screen.css
And I only write project specific CSS file included after this one so it’s like an “extension”.
I don’t really write any new HTML anymore, just use CMS and build it as combination of two and three columns layouts in my CMS and I only write CSS for each project. Every element I don’t need I simply hide in CSS (e.g. #basket, #search, etc). Gzip compression and expire setting on files and todays broadband speed doesn’t really need minimalistic HTML like 10 years ago, when I optimised my HTML/CSS code to minimum.
Your css looks similar to how I usually code as well. Not here on since it’s been awhile since I coded this site, but more recent projects.
Excelent explanation. Summarizing, the Pros are to set new and consistent default values, the Cons are to “rewrite” everything again, doing some “redundant” codes? I guess the Pros scores a touchdown! We can use CSS resets without major problems, at least for “pixel perfect” designers who want the exactly margins, paddings and gutter widths for their layouts. Since rewriting all the code we want does not affect page speed or the overall websites’ performance, I think use CSS reset is almost mandatory. That’s my point of view.
Thanks Edson. There’s definitely nothing wrong with using a reset. I hope I didn’t leave the impression that I’m against them at all. It’s more that I don’t think they should be treated as a black box. If you’re going to style an element you should remove that element from the reset.
I think many people drop a reset into a project and then go on to style everything in the reset. That won’t hurt anything, but there’s no reason to have the extra code there.
Hey Steven.
There are a lot of “copy&paste” coders out there these days, and I expect the black box phenomenon you describe in your article is fairly widespread, and not just with CSS resets. I applaud you for bringing it up.
Michael I agree. I think there have always been copy and paste coders out there. Some people want and are willing to learn how things work. Others just want to take the easiest way out.
I confess to leaving my reset code untouched at the top of my stylesheet in a lot of cases – not because I’m a copy/paste coder or I don’t know what I’m doing, but because I don’t always know what I’m going to leave in or take out until I’ve finished, and in my experience a site is never truly finished. Perhaps my code is a little larger than necessary, but compared to the other assets and resources in a site, such as images etc, a couple of kilobytes is not such a big deal.
I like the fact that there’s a reset at the start of the file that produces a clean foundation for any other code I want to add. I know with confidence that if a client comes back to me at a later date and wants changes making to the css, that I can make them knowing that a good solid reset and the cascade are all I need. I don’t need to go back and repair my reset so it all works again.
I can see both sides here – a trimmed reset would be the most efficient code, but it’s not necessarily the most usable.
To be honest the reset shouldn’t be necessary at all. This standardisation should be part of the browser. I shouldn’t be judged for the shape and size of the sticking plaster I use to repair someone else’s inconsistencies.
I confess to having done it as well and for the same reason. You don’t always know when you begin coding exactly what you’re going to need. Still it’s best practice to go back later and at least remove those things you have coded.
I certainly don’t want to imply that resets are bad. They absolutely serve a purpose. It’s mostly that I think we should be more conscious of why we’re adding them and deciding when we really need or don’t need some of the things they include.
You’re right too that there should be some defined set of defaults that all browsers follow. You’d think it wouldn’t even be that difficult to do. And yet I won’t hold my breath waiting for them.
This is a really interesting article! Thanks for the great compared and contrasted information.