To Reset or Not Reset — That’s the CSS Question

Every web browser uses a base stylesheet. It ensures HTML is rendered reasonably well when you don’t provide custom CSS. You know the kind of thing: blue for unvisited links, purple for visited links, bold for strong tags, larger text for h1 titles etc. Unfortunately, vendors love making our lives complicated and each browser uses a different base. So how can you ensure your custom CSS is not affected by a default style implemented on a specific device? Enter CSS resets. These strip most styles so elements are rendered consistently across browsers. Typically, all fonts and line heights revert to 100%, margins and padding are set to 0px, borders are removed, and ordered/unordered lists become unstyled. Eric Meyer’s CSS Reset was one of the first and is the most well known and used. The HTML5 Reset Stylesheet from HTML5 doctor can also help style newer elements. There are several others — CSSReset.com provides a great selection and documentation.

Do you use a CSS reset? Should you?

I’ve looked at a random collection of 30 websites and the majority used a CSS reset. The advantages are clear:

1. They provide a blank canvas; any styles applied are (almost) certain to be your own.
2. Development can be more logical: you’re adding styles rather than removing or modifying them.
3. Browser compatibility issues can be minimized.

Despite these advantages, I don’t use CSS resets. Actually, that’s not quite true — I often use the basic margin and padding reset because the default values are rarely useful:

* { padding: 0; margin: 0; }

This affects every tag and some developers will tell you it causes havoc or slower CSS processing. I’m yet to encounter a situation where it’s become problematical. My main issues with CSS resets are: Additional page weight Most CSS resets add around 2Kb of code (uncompressed). That may not sound much but it’s a large overhead when the majority of my CSS files rarely exceed 10Kb. Additional effort A CSS reset requires you to re-style all your elements — which adds further weight to your file. Sometimes though, I’m happy with the browser’s defaults. Font weights, line heights, link outlines, bullet discs and other styles are often fine. If they’re not, I’ll change them accordingly. Different browsers render pages differently No two browsers are the same yet some people expect pixel-perfect rendering across all devices. CSS resets often give the impression that this goal is achievable. It’s not. Personally, I don’t mind if titles in Firefox are 2px larger than IE or Opera’s idea of ‘bold’ is slightly heavier than Chrome’s. A CSS reset will never resolve those issues for you. They don’t negate the need for browser testing I’m not convinced CSS resets aid browser consistency. You must test your site or application in as many devices as possible so you can address errors and bugs caused by your code or the browser. They don’t fit with my workflow I’m not a fan of CSS frameworks. I rarely encounter situations where a generic CSS approach applies to the site being built. I may copy a few code snippets from elsewhere but, in general, I prefer to start with an empty file. It remains my code and I know exactly where to go when bugs arise. Although it’s not as complex, a CSS reset is a framework which can introduce unexpected results. They don’t save time Has a CSS reset ever saved you hours of development time? Before I’m attacked by an angry mob of CSS reset fans, I’m not saying you should never use them. They may they work for you and that’s fine. I suspect they’re also useful to those who are new to web development. However, are you adding a CSS reset because it’s genuinely useful or has it become a development habit? As a test, try removing the reset styles from your website to see if it makes a significant difference. Do you use CSS resets? Have you recently adopted or dropped the practice? Do they help?

Frequently Asked Questions (FAQs) about CSS Resets