Reset 2.0b2: Paring Down

Published 13 years, 9 months past

A few changes for beta 2 of the updated reset, presented here:

/* http://meyerweb.com/eric/tools/css/reset/ 
   v2.0b2 | 201101
   NOTE: THIS IS A BETA VERSION (see previous line)
   USE WITH CAUTION AND TEST WITH ABANDON */

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, img, ins, kbd, q, s, samp,
small, strike, strong, sub, sup, tt, var,
b, u, i, center,
dl, dt, dd, ol, ul, li,
fieldset, form, label, legend,
table, caption, tbody, tfoot, thead, tr, th, td,
article, aside, canvas, details, embed, 
figure, figcaption, footer, header, hgroup, 
menu, nav, output, ruby, section, summary,
time, mark, audio, video {
	margin: 0;
	padding: 0;
	border: 0;
	font-size: 100%;
	font: inherit;
	vertical-align: baseline;
}
/* HTML5 display-role reset for older browsers */
article, aside, details, figcaption, figure, 
footer, header, hgroup, menu, nav, section {
	display: block;
}
body {
	line-height: 1;
}
ol, ul {
	list-style: none;
}
blockquote, q {
	quotes: none;
}
blockquote:before, blockquote:after,
q:before, q:after {
	content: '';
	content: none;
}
table {
	border-collapse: collapse;
	border-spacing: 0;
}

First, the small changes: adding embed, output, and ruby to the first rule.  I went back and forth on these quite a bit, which is why they weren’t in the first cut.  However, none of them seem to be replaced so they’re in.  Others, such as command, are replaced and so stay out for the same reason that form inputs are left out.  (img is a special case.)

The HTML5 element I’m still stuck on is datalist, which seems sort of replaced but then again maybe not.  I’m really close to including it on the same grounds that I include canvas, but it’s hard to know if that’s a good idea.  If anyone with deep experience with datalist could explain what element it’s most like, and whether it’s really replaced or what, please do so.

Now the big changes: I removed the outline declaration from the first rule, which was option #2 in “Looking For Focus“.  I’d largely decided that was the best solution before I posted, but I didn’t want to say so for fear of skewing the responses either way.  It was interesting to see how that option initially didn’t come up very much, and then suddenly a bunch of people stumped for it.  Anyway, that course of action seems to make the most sense to me; for the reasons why, the comments of those who supported it pretty much sum up my thoughts.  With that declaration out, there’s no need to do anything special for :focus in subsequent rules.

Following on that, the other change is that I’ve dropped the :focus rule entirely, and also the ins and del rules.  Why?  Because all three of them are attempting, in some fashion, to impose a presentation above the baseline that the reset attempts to establish.  I basically left text-decoration alone in this reset; reset and del were the exceptions.  I can’t justify those exceptions any longer.

The rule for ins was actually interesting: it was, in spirit, exactly the same as the :focus rule.  Here’s a comparison:

/* remember to define focus styles! */
:focus {
	outline: 0;
}

/* remember to highlight inserts somehow! */
ins {
	text-decoration: none;
}

Both strip off a common visual styling and remind authors to define something visible.  Of course, pretty much nobody ever complained about the ins rule, but they’re conceptually the same and so if one goes, both should go.  And if I’m not keeping the ins rule, I can’t see any reason at all to keep the del rule.

So that’s where we are in beta 2.  I’ll be interested to know what you think.

Comments (15)

  1. Nice and helpful because of the additional support of HTML5 elements. But very often I remove the “table declaration”, because I often use table designs based on “border-collapse: separate”.

  2. I think you made the right call all the way around. I wouldn’t have argued one way or another for ins or del because I have never had need of them in production environments at any job I have had. Since they weren’t things on the forefront of my needs, I basically didn’t pay attention to them. That was wrong of me. I sincerely apologize to the community at large. ;-)

    However, now that you explain your rationale for the changes regarding them, I wholeheartedly agree.

  3. Eric wrote:

    I basically left text-decoration alone in this reset; reset and del were the exceptions.

    I think you meant ins here.

    I really like what you’ve done with this. Thanks Eric. (Am I the only one who thinks the mark tag was an Easter Egg for Mark Pilgrim?)

  4. As far as I can tell, [datalist] seems to be treated like the drop-down in a [select], so you’re right in not resetting it, as browsers will probably do their own thing with it anyway.

    Here’s a demo (currently works in Opera only)…
    http://html5.org/demos/dev.opera.com/article-examples.html

  5. I’m just wondering, do you need to reset the list-styles on ul & ol? are there any differences between browsers on that front?
    Aren’t all OL’s numerical, and all UL’s follow the nesting – black dot – white dot – square – square – square – etc…

    If not, you’d just be deleting the rule by default, or rebuild them using your own styles anyway.

    If you want a custom list style, then you set that list style either for your specific list or globally using the ul/ol selectors, somewhat like the :focus and the ins/del selectors.

    Unless you want to reset those to nothing so as to remove the nesting dots differences.

  6. WTF is the [ruby] tag?

  7. Nathan, thank you! That makes it a lot more clear. Also, Jeremy Keith’s recent pattern experiment helped once I remembered it and dug it up.

    Vidal, not all ordered lists are numerical. Some are alphabetic, in a variety of possible languages, and it’s even possible to put bullets on an ordered list. (You can also apply numbers or letters to an unordered list, but they don’t increment without further intervention.) This reset encourages close thinking about how to mark lists of both varieties. That said, I suspect it’s the rule that is most often removed by people adapting the reset to their own workflow.

    bill, it’s an element for marking up CJK phonetic content; here’s a good introductory explanation from the HTML5 Doctor crew. Not sure exactly why that rates a “WTF”, though.

  8. It’s complete? Looks smaller than previous version. Sorry for lazyness.

  9. Do you think it would be useful to include the focus selector, but without any rules? In other words,

    /* remember to define visible focus styles! */
    :focus {
    }

    This way, the user *shouldn’t* forget to define a style.

  10. I understand why you removed outline: 0 from the first declaration and feel it is justified. In v2.0 b1 I struggled with leaving the ins { text-decoration: none } in the reset since in my own base styles I do including ins styles. I then moved it from my base styles to where I had this reset and that felt off too. Finally I came to the conclusion to leave my styles for del and ins in the base styles area of my stylesheets because they are just that, base styling not reset styling — they are there as my default styling and not resetting.

    Hah, I am a bit at odds with the decision to remove :focus — since I have used that rule to remind me to do something with it in the stylesheet, although now that I finally am in a routine of doing :focus styling and tabbing through my page to make sure something shows I am letting go of that as well. =)

    I am looking forward to see what is in store for v2.0 b3 and enjoy reading comments of those who are more advanced in their knowledge and theory of how things get done with HTML and CSS. Thanks for revisiting the reset Eric! =D

  11. Pingback ::

    » [Friday Links] The Winter Semester Edition - Wayne State Web Communications Blog

    […] Reset 2.0b2: Paring Down […]

  12. What about adding:


    button {
    font:inherit;
    text-transform:inherit;
    }

    It may not be a reset per se, but it does prevent issues with further styling.

  13. I like this trimmed down version, though instead of completely removing these elements it would be nice to see a set of what you consider as optional baseline rules.

  14. blockquote, q {
    quotes: none;
}
blockquote:before, blockquote:after,
q:before, q:after {
    content: '';
    content: none;
}

    Why would anyone ever want to reset inline quotes just so they have to define them all over again? With this CSS reset, you’ll need hundreds of lines of CSS to restore inline quotes functionality back to it’s former state (for example, http://en.wikipedia.org/wiki/Non-English_usage_of_quotation_marks). To put this in perspective, the following code only fixes the functionality for English, French, Spanish, and Japanese.

    q::before {
    content: open-quote;
}
q::after  {
    content: close-quote;
}
q:lang(en) {
    quotes: "“" "”" "‘" "’";
}
q:lang(fr) {
    quotes: "«" "»";
}
q:lang(fr) {
    quotes: "«" "»";
}
q:lang(es) {
    quotes: "«" "»" "“" "”";
}
q:lang(jp) {
    quotes: "「" "」" "『" "』";
}

    Your quotes reset is extremely harmful, and you should remove it.

    P.S. It’s nice that you allow <code> tags in comments, but you’re completely forgetting about <pre> tags. It really screws up this comment. Also, what’s up with your #main blockquote p { text-indent: 2em; } CSS rule? You don’t indent p elements, so you shouldn’t be indenting blockquote elements either. Not to mention that there’s nothing that says blockquotes might have content in them that isn’t appropriate to indent.

  15. Eli, it’s my position that the dynamic generation of quotes is (to use your terminology) harmful, and so I reset them. Since you disagree, you’re perfectly free to remove those lines from your copy of the reset. As I’ve said many, many times, the reset is not meant to be used without alteration. It’s meant as a starting point.

    I disallow pre in comments because of the potential for abuse, though perhaps I should loosen up on that; in the meantime, I’ve edited your comment as I believe you originally intended to mark it up. As for the rest of your comments on my stylistic choices, they’re my choices and I’m satisfied with them.

Add Your Thoughts

Meyerweb dot com reserves the right to edit or remove any comment, especially when abusive or irrelevant to the topic at hand.

HTML allowed: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <em> <i> <q cite=""> <s> <strong> <pre class=""> <kbd>

if you’re satisfied with it.

Comment Preview