Is your CSS reset doing more harm than good?
You know the drill. Code the XHTML. Check. Validate. Check. Start the CSS style sheet with a reset. Che… Hold on there. Before you dump the latest and greatest CSS reset in your style sheet, you might want to think about what those style declarations actually do. If you’re resetting tags that aren’t in your markup or tags that don’t need to be reset, you could cause more problems than you fix.
In case you’re not familiar with CSS resets, they’re a list of style declarations you put at the beginning of a style sheet to undo, or reset, the default styles browsers apply to certain tags. This ensures that the styles you actually declare look consistent from browser to browser.
Some web developers use a declaration like this:
* {margin: 0; padding: 0;}
The asterisk, or universal selector, matches ANY element. Others take a methodical approach and list all the elements to be reset, whether the tag appears in their markup or not. Eric Meyer’s Reset Reloaded and Yahoo’s YUI CSS Reset are the best examples.
If you adopt either method, you can run into two problems:
- Extra code and processing overhead
When a browser is fed the universal selector method it tries to reset the margin and padding for EVERY element, even if the tag doesn’t allow margins and padding. That’s a lot of unnecessary work. The reset templates are better, but they still involve code that may never be used and can undo styles you might need. For example, the YUI reset setslist-styletononefor ordered lists. What are the chances you won’t want an ordered list to be numbered? - No fallback for missing styles
Let’s say you style a website and hand it off to a client or another web designer. That person then uses a tag that was reset but not restyled. Because there’s no browser default to fall back on, your layout could be compromised.
There’s a better alternative to overzealous resets…
Create a custom CSS reset for each layout
Rather than strip every tag or borrow someone else’s template, you can build a CSS reset that’s tailored to a particular layout.
1) Reset the most used, block-level elements:
html, body, div, h1, h2, h3, ul, ol, li, form, fieldset,
input, textarea {
margin: 0;
padding: 0;
font-size: 100%;
}
The font-size property fixes a bug in Internet Explorer 6 and 7. When em’s are used for relative font sizes, they exaggerate how fonts are scaled when text is resized. Setting the font size to 100% forces them to resize text like every other browser. (You can read more about it at A List Apart.) If your design doesn’t include special styles for form elements, you can leave those selectors out.
2) Reset unordered lists:
ul {list-style: none;}
I use unordered lists for navigation and apply custom styles to lists in content areas, so it’s easier to strip the standard bullets here. If you don’t mind the default bullets or would rather style lists on a case-by-case basis, you can skip this declaration.
3) Get rid of borders:
img, fieldset {border: 0;}
In addition to fieldsets, this turns off the border on images, which is important if you plan to use images as links.
4) Reset typographic styles:
h1, h2, h3 {font-weight: normal;}
em {font-style: italic;}
strong {font-weight: bold;}
I always restyle headings, and the bold and italic properties ensure every browser displays em and strong tags as expected.
So, a bare-bones CSS reset would look something like this:
html, body, div, h1, h2, h3, ul, ol, li, form, fieldset,
input, textarea {
margin: 0;
padding: 0;
font-size: 100%;
}
ul {list-style: none;}
img, fieldset {border: 0;}
h1, h2, h3 {font-weight: normal;}
em {font-style: italic;}
strong {font-weight: bold;}
Just place it at the beginning of your style sheet and start styling your markup. Whenever you come across a tag that’s not in your reset (e.g. different level subheadings, definition lists, block quotes), add it to the list. You’ll end up with a clean CSS reset that’s customized for your layout and allows the browser to use default styles when needed.
Where do you stand on CSS resets? Do you restyle every tag or let browsers have their say? Share your techniques in the comments.
About Jason Garrison
Jason is a freelance web designer and developer who has a healthy obsession with web standards. When he’s not knee-deep in code, you can find him in a meditative state communing with the universe.
22 Comments
Excellent post, my CSS reset file looked almost like yours, will fix it up and add your suggestions.
Thanks for the share.
My thought is that css resets stink for exactly the reason you pointed out. I assign “0″ margins and padding to the body element and I reset all top margins to “0.” Other than that, I allow the browser to help out some. It’s rather frustrating to have to dig through an enormous amound of code to find every single h2 for every section and change everything about it.
Excellent point there, Jason!
Just the other day I was wondering the same thing, why I continue using these general CSS resets, if they only cause more problems when people start customizing the design, or adding additional forms, etc.
You just convinced me to reconsider using a general reset…
Cheers!
Hmm I’ve never seen the reset using the universal selector. I use the one that target specific elements, and from there I may delete or add a few depending on the specific design itself.
I’m not about to hand over control to a sub-par browser that will definitely screw up the layout. I want to ensure I have control, rather than letting IE6 take over.
I start out by using the typical Eric Meyer, then make changes from there. I’d rather tell the browser how much space between paragraphs as opposed to letting the browser do it. There are too many inconsistencies across platforms to not use it.
I’ve just started using reset style sheets and so far I like them; however when it comes to adding extra header information I speed it up by grabbing the style sheet straight from yahoo (http://developer.yahoo.com/yui/reset/) rather than hosting it myself. Hoping the user has a copy already so that there is no need to download it again.
Thanks again for the article.
Thanks for your comments everyone!
Dumitru — I’m glad I could help you see the light. :)
Jason — I agree. I don’t feel comfortable letting the browser dictate styles either. But I try to take a conservative approach and only reset the tags I use. You never know what’ll happen to a website once it leaves your hands.
Greg — Good thinking using Yahoo! to grab the YUI reset. Reduces the number of HTTP requests to a single domain, which could speed things up a little. But the YUI reset is only 30 lines of code (you could cut that to a third or quarter of the lines with compression/optimizations). If you want to use their reset, you might consider just adding it to your own style sheet and skipping that extra HTTP request altogether.
My thoughts on the subject are similar. Resets seem to be common, to the point of being recommended as “best practice” in many web development tutorials. I’m not convinced that resets are best practice, but making your own “custom” reset is the best option, IMO, followed by a few of the well-known resets like the YUI or Eric Meyer resets… I wouldn’t want to just asterisk-reset everything.
I like Greg’s idea though– and taken a step further, you could probably add your custom CSS and/or reset to a CDN on the cloud. It would be literally pennies a month to host parts of your sites on CDN. Perhaps I should give it a try one month just for giggles.
Style reset sheets are not supposed to stay in production pages. They were originally used to give you a blank slate and force you to define your own styles. Once you had done this, you would then remove the resets. Voila. No unnecessary styles, and no browser inconsistencies.
I don’t know at point along the way people started using them as default style sheets, rather than their intended purpose, but it’s bad practice no matter which way you slice it to leave them in production pages.
I have a custom one I made that I always start out with, and sometimes I do remove specific selector resets. I would never plop any pre-made css reset into my code, it would definitely cause problems for me.
That image of you holding up the Twitter icon is made of win
I agree with everything you’ve said so far Jason, but I don’t know if I’m sold on the idea of letting go of my reset just yet.
I’m not sure where Derrick gets his information from, but as far as I’m aware, resets exist simply to create a normalized playing field thus eliminating much of the base-level browser inconsistencies which all of us are familiar with by now. I challenge anyone on this comment stream to pick a client and pull their reset css right now and see if they get a “voila” moment.
The way I see it, if including an additional 4K (or less) of CSS in my page will solve 75% of my coding problems, I say it’s bandwidth well spent, IMHO.
Kevin — Too funny! I’m glad you like it. :)
Mike — I’m not necessarily advocating that developers drop their CSS resets (although there are people out there who do that). I think they’re an important tool and I use one myself on every project. I’m suggesting that we consider the consequences of resetting default styles and only do what’s necessary to get the job done. A CSS reset isn’t just a block of code from Yahoo! or Eric Meyer. It’s a set of styles with a specific purpose, something you can easily put together yourself that’s tailored to your specific layout. It’s never a good idea to rely on a piece of code (markup, style declarations, or otherwise) if you’re not clear about how and why it works.
I’ve been in the web development game so long now that I’ve actually become used to all the different browser nuances so they don’t bother me, and when I have come across a reset CSS it actually causes me more hassle and forces me to write extra styles to accommodate for the missing defaults. I suggest people stay away from reset css written by others and write your own so it caters to that specific project’s requirements.
It’s a small web – coincidentally my first post on our new BBC developer blog went out yesterday on this very subject, and it looks like we broadly agree too. Certainly *{} just doesn’t cut it.
Yes, CSS resets do help a lot. I didn’t use them before but ever since I started using it, I never looked back..The best thing I love about it is that it helps prevent those weird whitespaces or margins which you don’t want or forgot to remove..
By the way, love your “Did you enjoy the post” section.. the way you are holding the twitter icon lol.. pretty innovative though ;)
this is great. I’ve used both the Yahoo and Eric Meyer resets and the * reset, and while the have there good points and bad points, none of them a perfect.
I’m going to give the custom reset a go on the next site I do.
I think this is a better approach than either the splat (*) method or the declare everything.
Great points in this post. Some basic, but often forgot ideas about resetting only elements used in a certain design so as to prevent any future issues.
Jason, firstly, I really like your site design and colors, great job on the design here.
But regarding this article — I largely disagree. I don’t think the overhead caused by the extra style declarations is anything to worry about nowadays. There are more important ways to speed up a page, and clearing 10 lines of CSS is not on that list.
Also, a developer who inherits a project should be responsible for styling an element. Allowing an element to “assume” styles that were implemented by a previous developer does not conform to proper development processes. Besides, if there is an element that the original designer wanted styled a certain way, he would have done it.
And imagine what my client would say if I told them they had to pay me to style 20 HTML elements that are not currently on his site, but that might be on there a year from now. I seriously doubt he would agree. And I certainly wouldn’t want to do that for free. And how would I know the client liked the way they were styled, unless I showed them each one?
Also, it’s most likely that the new developer is going to style the element anyhow, so the best way for him to do so cross-browser is to start from a reset element.
But thanks for the topic, this is a good discussion point.
Louis — I’m glad you like the site, and thanks for adding to the discussion.
With regard to your comment about clearing 10 lines of CSS overhead, I have to disagree. Code optimization is a holistic process. A combination of many small adjustments can be just as effective as a few major ones. If you have a system in place (like I’ve proposed here) and develop a habit of clean coding, then optimizations like this are built right in so there’s no extra expenditure of the developer’s time or the client’s money. That and if I were a client, I’d have to question a developer who’s not concerned with 10 lines of code. What else might he or she not be concerned with that’s important? Just one of the many reasons why I build my own sites. :)
I agree that a developer who inherits a project “should” style elements, but mistakes can be made and you also have to account for situations like CMS’s where the client adds their own code. Only resetting the tags you use means there’s a fail-safe in those cases. Your comment that you don’t think a client should pay to style 20 elements that aren’t on the site speaks to this. If a developer doesn’t want to style those 20 elements, then he or she shouldn’t strip them with a blanket CSS reset. Again, a custom, targetted reset would solve the problem.
Hey, Jason.
I still disagree with your comment about not stripping the 20 elements. Think about it: There’s no way the new designer is going to put those elements in without styling them. Thus, by having them “reset”, it prepares them for cross-browser styling. Leaving them with potentially varied appearance in different browsers is pointless, really, in my opinion.
Also, imagine designing a business card for someone and creating 10 extra graphics that are not actually on the card, and giving them to the client, with a note that says: “Here are 10 more graphics that, if included in future designs, should look like this.”
But I do see your point, and I respect your opinion. It’s definitely nice to see a blogger who is willing to write something that might ruffle a few feathers. I find nowadays a lot of people are just rehashing the same old things without taking any risks. Thanks, I’ll be checking out more of your stuff in the future.