After a bit of time to bake and a few more suggestions from readers, I have what I’m willing to call the final version of my take on the topic of reset styles. To wit:
html, body, div, span, applet, object, iframe,
h1, h2, h3, h4, h5, h6, p, blockquote, pre,
a, abbr, acronym, address, big, cite, code,
del, dfn, em, font, img, ins, kbd, q, s, samp,
small, strike, strong, sub, sup, tt, var,
dl, dt, dd, ol, ul, li,
fieldset, form, label, legend,
table, caption, tbody, tfoot, thead, tr, th, td {
margin: 0;
padding: 0;
border: 0;
outline: 0;
font-weight: inherit;
font-style: inherit;
font-size: 100%;
font-family: inherit;
vertical-align: baseline;
}
/* remember to define focus styles! */
:focus {
outline: 0;
}
body {
line-height: 1;
color: black;
background: white;
}
ol, ul {
list-style: none;
}
/* tables still need 'cellspacing="0"' in the markup */
table {
border-collapse: separate;
border-spacing: 0;
}
caption, th, td {
text-align: left;
font-weight: normal;
}
blockquote:before, blockquote:after,
q:before, q:after {
content: "";
}
blockquote, q {
quotes: "" "";
}
So what changed from the last iteration?
I added background: transparent; to the first rule. It’s probably not as necessary as some of the other bits here, but it seemed like a good thing to add.
Added a :focus rule to try to suppress link outlining. Why? So that you remember to define your own. You should make sure to define an outline, as it’s an important accessibility aid. If you have a universal default, one that applies no matter what the project, then replace my rule with your own.
There’s now a body rule that sets a baseline line-height that will be inherited by the rest of the document (and can be overridden easily), and sets a foreground and background color. Originally, I avoided setting the colors, but decided it was better to put them in. Of course, if you have preferred color defaults other than black on white, edit the declarations to suit your taste.
The a img, :link img, :visited img rule has been dropped. This is because the only browser family it really affects is Gecko line, and they all honor author styles as having precedent over user agent styles (as they should!). So this is already covered by the first rule.
Added a rule for caption, th, td to be left-aligned and normal-weight.
Added a blockquote, q rule to suppress quotes by way of the quotes property. This has the same intent as the previous rule, but approaches it along a different route.
I also asked for help in figuring out how to simulate inherit in IE/Win. In the end, it seems to me like doing so isn’t really necessary for most people. As I said before:
[The
inherit] 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.
So that works for me, and I think for most people who have outlooks similar to mine. But maybe you develop primarily in IE/Win, or you really want to have IE/Win handle as many of these resets as humanly possible. In that case, you have two basic choices.
Use the script and syntax contributed by Jonathan Snook and Dean Edwards. Note, however, that Dean himself doesn’t recommend doing this, feeling that it’s too computationally expensive for such a small effect. Dean has a lot of experience with scripting around IE/Win’s limitations, so I give his views on this a lot of weight. On the other hand, I’d like to see IE/Win be able to honor inherit, or at least get the same behavior, so I might still use the script. (Though I’d be even happier with a script that just tacked itself onto instance of inherit in a style sheet, like Dean’s IE7 script does for other CSS stuff.)
Put in your own expressions, along the lines suggested by Priit and thacker. It’s not quite the same thing, but it’s a pretty decent approximation.
Like I say, these aren’t necessary unless you’re really sold on the idea of IE/Win being forced into line with everyone else and don’t mind paying the computational overhead. If so, then you can extend your own reset styles as needed.
That’s much of the point here: that this is not a case of “everyone must use these styles in a certain way without alteration”. Nor am I saying that everyone must use them or else be cast into darkness. Remember before that I termed these “my take on the topic of reset styles” (emphasis added). Your take may be subtly or greatly different. Think of these as a starting point for creating your own defaults, in addition to being a way to illuminate the nature of browser defaults. Simply the act of taking those defaults into consideration and thinking about them closely puts you ahead of 99% of your peers. I do think that reset styles are quite useful; otherwise, I wouldn’t have written about them here, and certainly not to the extent that I have. My hope is that people will use them as a launch pad for their own resets and for deeper thinking about styling and browsers.
My thanks to everyone who commented, not just those I linked above. And yes, I’m going to get to that “weirdness of form elements” post in the near future.
Addendum 2 May 07: I edited the CSS to change background: transparent to background-image: transparent, as it was supposed to be from the outset but I somehow didn’t see in any of the three times I looked over the declarations. So I guess that makes this post now “final.0.1”.
Addendum 4 May 07: background-image: transparent? There’s a big ol’ WTF. Apparently my cold medication has warped me a lot more than I believed. I’ve taken out that whole declaration and will not be editing the styles any further until I’m off the meds. So, not quite final, apparently.
Get over there, read the short introduction, and make with the answering! It shouldn’t take more than ten minutes or so, and your participation is essential.
Also, please spread the link far and wide—it works best if as many people as possible take it, not just ALA readers. Posting word in any relevant groups, forums, lists, etc. would be awesome. Put the word on the street! Please. Thanks!
The reset styles are currently held up on a point of non-support in IE/Win. However, there’s a decent chance we can work around it. I’m hoping you (or someone you know) can help.
One of the things I indicated was problematic, but that I would keep, was the use of inherit for a few properties. This value isn’t supported by IE/Win, and while I’m okay with including it anyway, it could cause confusion for others trying to use my reset styles.
Priit Pirita suggested the use of IE expressions to simulate inheritance. For example:
font-style: expression(
this.parentNode.currentStyle ?
this.parentNode.currentStyle.fontStyle :
‘normal’);
That would assign the weight of the parent element for any element whose parent had a currentStyle, and fall back to normal in any case where that wasn’t true.
Cool enough, assuming you’re okay with using expressions, but there are a couple of wrinkles I haven’t quite worked out. The first is this:
font-family: expression(
this.parentNode.currentStyle ?
this.parentNode.currentStyle.fontFamily :
‘[...???...]’);
What should be filled in for the [...???...]? The font family that IE/Win uses by default when first installed? A null value? Something else? I dunno. Hopefully someone here does.
The second problem is that some people have reported errors generated by expressions; see this comment by thacker for an example. Can anyone explain why those errors happen and how to avoid them?
The end goal here is not only to come up with inherit equivalents for font-weight, font-style, and font-family, but also to come up with a generic method of simulating inherit for any property. Doing so would be an enormous boon to developers, so here’s hoping we can pull together and solve this puzzle. Thanks!
The 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.
Over the weekend, I reworked meyerweb’s sidebar a bit. One of the changes is the addition of a section called “Identity Archipelago“, which links to various bit of my online identity and makes use of XFN‘s me value. I’ve been meaning to do this ever since co-presenting a poster on how me could be used to accomplish identity consolidation, and hey, I’m only thirty months late.
I ran into an interesting dilemma as I assembled the links, though. Should I link to the Wikipedia entry about me, and if so, does it really merit a me marker? I’m not so sure. Yes, the page is about me, but it isn’t something I created, nor is it something I control. Thanks to the open nature of Wikipedia, it could be altered to state that I’m a paste-eating pederast with pretensions to the Pakistani presidency. It would be kind of embarrassing to link to something like that, let alone proclaim in a machine-parseable way that the information on the other side of the link represented me in some way.
While I’ve never stated a Wikipedia policy, as others have, I’ve privately maintained a hands-off policy. Even though I’d like to replace the picture with a better one and flesh out some details of my career, and on occasion have wanted to correct some inaccuracies, I’ve refrained from doing so. I’m not going to proclaim that I’ll never ever edit my own entry, because if libel (alliterative or otherwise) shows up and I’m the first to notice, I’ll at least roll the page back. But in general, I’m keeping my hands off.
Nevertheless, it is arguably a piece of my online identity. Not linking to it feels like a glaring omission—or am I just trying to rationalize an egocentric desire to show off? I don’t think that I am, but then I’m hardly a neutral party.
So what’s your perspective? Is a Wikipedia entry created and edited by others properly a part of my archipelago, or is it simply a nearby island?
Here’s the latest version of my “baseline” style sheet, with some changes based on feedback from readers on the original post.
/* Don't forget to set a foreground and background color
on the 'html' or 'body' element! */
html, body, div, span,
applet, object, iframe,
h1, h2, h3, h4, h5, h6, p, blockquote, pre,
a, abbr, acronym, address, big, cite, code,
del, dfn, em, font, img, ins, kbd, q, s, samp,
small, strike, strong, sub, sup, tt, var,
dd, dl, dt, li, ol, ul,
fieldset, form, label, legend,
table, caption, tbody, tfoot, thead, tr, th, td {
margin: 0;
padding: 0;
border: 0;
font-weight: inherit;
font-style: inherit;
font-size: 100%;
line-height: 1;
font-family: inherit;
text-align: left;
vertical-align: baseline;
}
a img, :link img, :visited img {
border: 0;
}
table {
border-collapse: collapse;
border-spacing: 0;
}
ol, ul {
list-style: none;
}
q:before, q:after,
blockquote:before, blockquote:after {
content: "";
}
The changes are:
The leading comment — rather than fill in some default document colors, which I hesitate to do given how often they’ll be changed, I just threw in a comment reminding the author that setting them is a good idea. I’d expect that anyone who uses their own set of baseline styles will fill in their own favorite color set.
font-weight: inherit; — this used to be normal, but it was pointed out that this would upset normal inheritance. For example, if you set a div to be boldfaced, none of its descendant elements would inherit that boldness (because they’d be explicitly assigned normal). Using inherit avoids this problem while still “zeroing out” boldface styling.
font-style: inherit — same reasoning.
vertical-align: baseline — this brings everything onto the baseline, including superscripts and subscripts. This forces authors to determine the exact vertical offset they want for such elements, as well as any others they might care to vertically shift, as well as how they’ll accomplish said shift(s).
a img, :link img, :visited img — this will make sure images in anchors and links don’t have a border by default. Using a img covers images in named anchors, while the rest of the selector handles images inside either visited or unvisited links. You might consider a img to be sufficient, and for now you’d be right. But in the future, any element may be a link, not just a elements, so this gives us a bit of future-proofing.
I also put some spaces into the selectors to make them easier for me to read. If you use these styles, you might consider stripping out the unnecessary whitespace to compact the rules as much as possible.
It was suggested that min-width: 0; be added to the first rule in order to invoke hasLayout, but Ingo Chao explained why that was a bad idea. It was also suggested that text decorations should be removed from links, but I’d rather not. I try never to mess with link decorations, and also figure that anyone who feels otherwise can add their own text-decoration declarations.
So we’ll see how well this one stands up to use in the wild. Let me know!
At AEA Boston, I advocated using a “reset” or “baseline” set of styles, but not one based on the universal selector. Instead, I said the styles should list all the actual elements to be reset and exactly how they should be reset. During the Q&A afterward, an audience member asked me if I would create such a style sheet to share with the world, and I said that I would.
Then, during the break, someone else (sorry I’ve forgotten who!) reminded me that the Yahoo! UI group already did it with reset.css so I don’t have to. Awesome!
…except that I don’t think it goes far enough in some areas, and a little too far in others. So here’s my version of reset.css, based off of the YUI styles.
html,body,div,span,
applet,object,iframe,
h1,h2,h3,h4,h5,h6,p,blockquote,pre,
a,abbr,acronym,address,big,cite,code,
del,dfn,em,font,img,ins,kbd,q,s,samp,
small,strike,strong,sub,sup,tt,var,
dd,dl,dt,li,ol,ul,
fieldset,form,label,legend,
table,caption,tbody,tfoot,thead,tr,th,td {
margin: 0;
padding: 0;
border: 0;
font-weight: normal;
font-style: normal;
font-size: 100%;
line-height: 1;
font-family: inherit;
text-align: left;
}
table {
border-collapse: collapse;
border-spacing: 0;
}
ol,ul {
list-style: none;
}
q:before,q:after,
blockquote:before,blockquote:after {
content: "";
}
I omitted elements like hr and the various frame-related elements, as well as form elements like input and select, because of their general weirdness, though I may change my mind about those at a later date. I intentionally left out dir and menu because of their deprecated status.
I’m absolutely open to questions, comments, and suggestions, so feel free to use the comments for that purpose.
(Side note: if anyone’s disturbed by the unitless value for line-height, please read my post “Unitless line-heights“.)
Addendum: There have been some good suggestions in the comments, so they’re definitely worth reading. See also the followup post, which incorporates some of those suggestions.