A wordy history of default browser styles and CSS Resets
Yep, if you keep reading, you’re going to encounter numerous paragraphs of information about how browsers render HTML, why they do it differently, and what you can do about it.
Write some basic HTML and look at it in your browser. Notice that headers are bold, paragraphs have spacing, links are blue (or purple if visited), lists have bullets and are indented, buttons look like actual buttons, and tables have padding. These styles are applied by something called a ‘user agent stylesheet.’ Pretty easy to tell one element from another, right?
Now look at that HTML in different browsers. Notice that headers are bold in slightly different ways, elements have different padding, paragraphs are spaced differently, button appearance varies wildly, and lists…you should just inspect lists using each browser’s native developer tool.
These default styles are set by the user agent, otherwise known as the browser. Each browser, and often each release version of a browser, has a slightly different set of default styles. These differences are the bane of web developers far and wide.
Introducing CSS Resets
To circumvent this rendering problem, many developers use a CSS reset — a small CSS file that strips browsers of their default styles. According to a comprehensive Six Revisions article about CSS resets, The first baseline resetting stylesheet was probably introduced in 2004. Eric Meyer was the first to popularize the concept, and introduced his own version, adapted from one created by Yahoo, in 2007.
Today there are dozens of reset snippets available, each of which takes a slightly different approach to priming the canvas for developers. It’s dead simple to link to a reset file and not give a second thought to the original issue.
But why were user agent stylesheets so different to begin with? Why did browsers include default styles at all? Are they still that different? Are resets even necessary anymore? I’ve spent hours of googling to figure this stuff out. Here’s what I found:
The origin of user agent stylesheets
Default browser styles originated as a World Wide Web Consortium (W3C) recommendation. For readers who’ve never heard of the W3C, it’s an international organization that develops and recommends standards for the web.
According to their first CSS standards documents,
Each User Agent (UA, often a “web browser” or “web client”) will have a default style sheet that presents documents in a reasonable — but arguably mundane — manner.
CSS Level 2 standards contained a similar directive:
Conforming user agents must apply a default style sheet (or behave as if they did). A user agent’s default style sheet should present the elements of the document language in ways that satisfy general presentation expectations for the document language (e.g., for visual browsers, the EM element in HTML is presented using an italic font).
The W3C set this standard for accessibility purposes. Without default styles, web users who can’t or choose not to render CSS would encounter a giant grey wall of text instead of a readable document with basic formatting.
Why default browser styles differed
In its standards, the W3C kindly provides a sample default stylesheet, but doesn’t set any specific requirements for individual element styles. So from the beginning, browser programmers have gone it alone. The result — each browser has its own idiosyncrasies when rendering basic styles.
Why default browser styles *still* differ
Good question. I’ve now invested far more time in researching this question than any reasonable person should. My conclusion: because browser vendors are in a strange and tangled competition for business that results in all sorts of nonsense and bad behavior. Meanwhile, the W3C doesn’t have any power to enforce the web standards it recommends.
For what it’s worth, I don’t fault browser vendors for competing with one another. The browser wars lead to a great deal of innovation, and the World Wide Web is better for it. But competition does not equal obstinate refusal to acknowledge and fix a simple but universal problem.
Ok, fine, but do I need to use a CSS reset?
Google “CSS reset” and you’ll find all sorts of arguments for and against, as well as a seemingly endless debate about which reset tool is best. My answer: yes, no, maybe.
CSS beginners should use resets while they’re learning the basics of styling. User agent styles cause weird problems that will only interfere with the learning process.
Once you’re comfortable with styling, work on projects without resets and create your own default styles on a case-by-case basis. Doing so will deepen your understanding of what’s happening under the hood. You might end up with your own reset file that fits your workflow.
CSS resets can save advanced web developers a lot of time if they need to spin up a complex project quickly and will be styling lots of different components. Also, most CSS frameworks include reset files, so if you’re Bootstrapping, you’re also Normalizing. But because CSS resets zero out all styles from most html elements, developers can find themselves rewriting a bunch of styles and unnecessarily increasing the number lines in their CSS.
Dana, I made it this far. What do you do?
I take a hybrid approach. I don’t want to reinvent the wheel; if I want to reset an element’s styles, I’ll pull code from an existing reset file. But I don’t just stick a full reset file into my code. I care about web accessibility, and I don’t want to unknowingly make an element inaccessible.
So there you go. More than you likely ever wanted to know about CSS resets. But I don’t know your life. Maybe you read every word. Twice. Hey, if that’s the case, get in touch. I like fans.
