Reset Reasoning
Published 18 years, 1 month pastThe reset styles are undergoing yet another overhaul, but in the meantime, I thought I’d answer a question several people have asked: why?!? Why do this at all?
The basic reason is that all browsers have presentation defaults, but no browsers have the same defaults. (Okay, no two browser families—most Gecko-based browsers do have the same defaults.) For example, some browsers indent unordered and ordered lists with left margins, whereas others use left padding. In past years, we tackled these inconsistencies on a case-by-case basis; for example, making sure to always set both left padding and left margin on lists.
But there are all kinds of inconsistencies, some more subtle than others. Headings have slightly different top and bottom margins, indentation distances are different, and so on. Even something as basic as the default line height varies from one browser to another—which can have profound effects on element heights, vertical alignments, and overall feel.
This is not something we consider very often. We think of our CSS as modifying the default look of a document—but with a “reset” style sheet, we can make that default look more consistent across browsers, and thus spend less time fighting with browser defaults. Rather than say “the size of that heading is just right”, forgetting that not all browsers size headings the same way, I have to write the CSS that sets the heading to be the size I want (or the design requires, which comes to the same thing).
This is why so many people zero out their padding and margins on everything by way of the universal selector. That’s a good start, but it does unfortunately mean that all elements will have their padding and margin zeroed, including form elements like textareas and text inputs. In some browsers, these styles will be ignored. In others, there will be no apparent effect. Still others might have the look of their inputs altered. Unfortunately, there’s just no way to know, and it’s an area where things are likely to change quite a bit over the next few years.
So that’s why I don’t want to use the universal selector, but instead explicitly list out elements to be reset. In this way, I don’t have to worry about munging form elements. (I really should write about the weirdnesses inherent in form elements, but that’s for another day.)
There’s another reason I want to reset a whole lot of styles on a whole lot of elements. Not only do I want to strip off the padding and margins, but I also want all elements to have a consistent font size, weight, style, and family. Yes, I want to remove the boldfacing from headings and strong elements; I want to un-italicize em and cite elements.
I want all this because I don’t want to take style effects for granted. This serves two purposes. First, it makes me think just that little bit harder about the semantics of my document. With the reset in place, I don’t pick strong because the design calls for boldfacing. Instead, I pick the right element—whether it’s strong or em or b or h3 or whatever—and then style it as needed.
The maddening barrier to this is, yes, Internet Explorer. See, in order to set all elements to have the same font weight and style (both normal) and have all elements use the same font face without breaking inheritance, I need to declare the following:
font-weight: inherit; font-style: inherit; font-family: inherit;
But IE/Win doesn’t support inherit, which would seem to bring that whole effort to a screeching halt. I can’t explicitly assign the values, like I did in a previous version of the style sheet, because that would block the effects of inheritance. Say, for example, I wrote this instead:
font-weight: normal; font-style: normal; font-family: serif;
Okay, now I have this rule later on in the CSS:
h1 {font: bold 2em Verdana, sans-serif;}
Then I have this markup:
<h1>Considering a <em>Truly</em> Annoying Omission</h1>
The em in the middle of the h1 will be un-boldfaced, and in a serif face. With the inherit values, it would be bold and in Verdana (or some sans-serif font). I should have realized that from the outset, but sometimes my enthusiasm gets ahead of my reason.
So do I drop those inherit declarations? In the end, no. They won’t work in IE/Win, but since I develop primarily in Firefox and Safari, that’s not actually a problem. Their effects, as seen in my development environment, will still serve the purpose of reminding me to build up the styles I actually want, and not use the browsers’ defaults as a crutch. There is the possibility of my forgetting that (for example) IE/Win italicizes em when I don’t want it to, but that’s something I’ll catch during the browser testing phase.
Hopefully this helps clarify my motivations and thinking. I’ll follow up with a new (and hopefully final) version of the reset styles in another post, along with commentary on what other things I changed.