HTML5 Reset Stylesheet

We’ve had a number of people ask about templates, boilerplates, and styling for HTML 5. Last week, Remy introduced some basic boilerplates for HTML 5, so to keep the momentum going, I’ve modified Eric Meyer’s CSS reset for you to use in your HTML 5 projects.

The code

Let’s start with the complete CSS stylesheet:

/* 
html5doctor.com Reset Stylesheet
v1.4.1 
2010-03-01
Author: Richard Clark - http://richclarkdesign.com
*/

html, body, div, span, object, iframe,
h1, h2, h3, h4, h5, h6, p, blockquote, pre,
abbr, address, cite, code,
del, dfn, em, img, ins, kbd, q, samp,
small, strong, sub, sup, var,
b, i,
dl, dt, dd, ol, ul, li,
fieldset, form, label, legend,
table, caption, tbody, tfoot, thead, tr, th, td,
article, aside, canvas, details, figcaption, figure, 
footer, header, hgroup, menu, nav, section, summary,
time, mark, audio, video {
    margin:0;
    padding:0;
    border:0;
    outline:0;
    font-size:100%;
    vertical-align:baseline;
    background:transparent;
}

body {
    line-height:1;
}

article,aside,canvas,details,figcaption,figure,
footer,header,hgroup,menu,nav,section,summary { 
    display:block;
}

nav ul {
    list-style:none;
}

blockquote, q {
    quotes:none;
}

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

a {
    margin:0;
    padding:0;
    border:0;
    font-size:100%;
    vertical-align:baseline;
    background:transparent;
}

ins {
    background-color:#ff9;
    color:#000;
    text-decoration:none;
}

mark {
    background-color:#ff9;
    color:#000; 
    font-style:italic;
    font-weight:bold;
}

del {
    text-decoration: line-through;
}

abbr[title], dfn[title] {
    border-bottom:1px dotted #000;
    cursor:help;
}

table {
    border-collapse:collapse;
    border-spacing:0;
}

hr {
    display:block;
    height:1px;
    border:0;   
    border-top:1px solid #cccccc;
    margin:1em 0;
    padding:0;
}

input, select {
    vertical-align:middle;
}

So what’s new?

Quite a bit! The next few sections explain what I changed and why I changed it.

The basics

I started by removing elements that have been deprecated from the HTML 5 specification, like <acronym>, <span> and <big>. (We’ll cover deprecated elements in more detail in another post). I also added new HTML 5 elements, like and, in order to remove any default padding, margin, and borders. I’ve also added an explicit display:block property for elements that are required to render as blocks.

I also removed the explicit unstyling of the :focus pseudo-class. There are two reasons for this. First, by declaring outline:0, you remove the focus identifier for keyboard users. Second, Eric released his stylesheet in good faith that people would explicitly style :focus, but they generally don’t, so it’s safer to leave the default :focus styles in place. (I also set defaults for <ins>, since I don’t think that got updated very often either.)

I’ve left the default list styles in place simply as a personal preference. I tend to add the list style back when using Eric’s reset anyway. I have, however, included nav ul {list-style:none;} to remove those pesky bullets from your navigation.

### Using attribute selectors

You’ll notice that I’ve included attribute selectors for <abbr> and <dfn>. This way, the style will only appear if there is a title attribute on the element. This is primarily for accessibility. For example, we use <abbr> regularly on this site but don’t always include a title attribute. We think it’s safe to assume all of our readers (no matter what device they’re using) know what HTML stands for. We do still use the <abbr> element to make sure screen readers read the text as H-T-M-L rather than struggling to pronounce “HTML”.

### What’s that bit about mark?

is a new element introduced in <abbr>HTML</abbr> 5 used to (you guessed it) mark text in a document. According to the spec: <q>"The mark element represents a run of text in one document marked or highlighted for reference purposes, due to its relevance in another context."</q>. I anticipate it will be used for highlighting phrases in search results and other similar purposes. We'll post more on soon.

## Where are all those application elements?

“Application elements” is a term I’ve loosely used to describe elements like ,, etc. These elements are more likely found in web apps than web sites. I left these out since, at the time of writing, browsers implement barely any of what was “Web Applications 1.0″. Also, this stylesheet is intended primarily for authors serving their pages as text/html, not XML.

## Go grab it

The stylesheet is released under a Creative Commons license, so you can use it for both personal and commercial work. I thought I’d let Google take care of the hosting, so go grab it from Google Code and let us know about any improvements you make!

* HTML 5 Reset Stylesheet

Share and Save:
  • Twitter
  • Digg
  • Sphinn
  • Reddit
  • del.icio.us
  • StumbleUpon
  • Technorati
  • Netvibes
  • Facebook
  • Google Bookmarks
  • FriendFeed
  • HackerNews
  • LinkedIn
  • NewsVine
  • Tumblr

86 Responses to “ HTML5 Reset Stylesheet ”

Comment by Martin Kliehm at

Hi Richard,

outline:0 on anchors is a big accessibility issue because keyboard users can’t see the focused element anymore. And a background color (ins, mark) should never be set without a text color. I’d suggest to fix that.

Thanks,
Martin

Comment by zcorpan at

You list menu twice in the first and third rulesets. (menu is display:block in browsers already so no need to include it.)

source is an invisible element so doesn’t need any resets.

blockquote doesn’t have quotes by default.

I would argue against removing quotes from the q element — if you use both the q element and quotation characters then you get double quotation characters in the feed reader and in non-CSS browsers such as Lynx. If you’re going to use quotation characters then don’t use the q element at all.

I would also suggest to not use cursor:help since personally I find it annoying and also some people think that something will happen when they click it (since it normally does in the OS).

/* tables still need ‘cellspacing=”0″‘ in the markup */
Why?

border-spacing and cellspacing have no effect in the collapsed table border model anyway. and cellspacing is an obsolete attribute in HTML5.

Comment by Rich Clark at

@martin ah good spot, removed the :focus but forget the anchor in the opening rules, now moved on it’s own. Also thanks for the colour reminder.

@zcorpan ah must have missed source when removing elements from that rule, thanks. Also good on spot on menu, no matter how much checking you do something always gets missed eh?

Didn’t realise that cellspacing was obsolete now, however it has now been removed.

I think the help cursor can be handy, but can understand your concerns that people may think it signifies a link for example.

I did think about including quotes by default but have decided to leave this as found in Eric’s reset.

Cheers

Rich

Comment by Adam Harvey at

Thanks for this, I’d already cobbled together my own version, but this one is much more comprehensive and built with a better understanding of just what the hell is going on with HTML5.

Comment by Juraj at

Nice code, but is CSS reset necessary? What are real advantages of CSS reset?
I think it is illogical to remove blockquote’s margin, or set e.g. border:0 to elements, which don’t have any default border.

Comment by Florent V. at

CSS Resets: polluting your Firebug(/Web Inspector/etc.) style information and breaking keyboard accessibility in a web project near you.
There are some ideas that i may use in my own CSS Unreset (aka base stylesheet), though.

A few comments on some details:

1. The part for killing automatic quotes looks a bit too convoluted. First, i think there is no need to apply specific rules for that to BLOCKQUOTE elements. I have never seen a web browser that uses automatic quotes for the BLOCKQUOTE element. Then, for the Q element, Firefox and Opera (and maybe IE8?) will accept q{quotes:none;}, but not Webkit. For Webkit you need q:after,q:before{content:”";}. But then my guess is that if you use this line, you don’t need q{quotes:none;}. So you may be able to replace your nine lines of code with just:

q:before, q:after {
content:”;
}

Obviously you should check that it works first. Maybe you already did?

2. For the border on abbr and dfn, you may want NOT to specify a color, and let the browser use the text’s color. I use border:1px dotted;, but i have not tested it extensively.

3. About the “tables still need ‘cellspacing=”0″‘ in the markup” statement, which comes from Eric Meyer’s stylesheet if i remember correctly: i have never found that to be true. Maybe i missed it. I write tables without that attribute and never had a problem because of that. Is that a IE5 or NN6 or IE Mac limitation? If this is the case, then that comment could be discarded.

4. In the first and third selectors, you have the MENU element twice.

5. You write about outline:none on a:focus which kills link focus when navigating with the keyboard. But, at least on Firefox, having outline:none on the A element (with no particular pseudo-class) does the same. I wrote this test page (the first CSS styles apply to all links in the page, the following ones apply only to the relevent section): http://covertprestige.info/temp/liens-focus-active.html The goal is to keep the browser’s default highlighting of focused links, and to avoid this highlighting when links are clicked. In my tests, a:active {outline:none;} works perfectly (with no accessibility issue i can think of) in Firefox 3.0 and 3.5, Safari 3 and 4, Opera 9.6 and 10 (actually Opera forces a very strong focus style when using keyboard navigation, and won’t allow style authors to override it, so it’s not a surprise), AND IE8. It doesn’t work with IE 6 and 7, but those don’t implement the outline property anyway (and have a buggy implementation of :active).

I may have forgotten something, but a:active {outline:none;} looks like a winner to me.

Comment by Florent V. at

“is CSS reset necessary?”

I think not. CSS resets have their advantages but then they have their problems too. If you take the definition of a reset stylesheet literally, you have to make the display of every single element as neutral or blank as possible. Some reset stylesheets do that, but this one doesn’t. If you read it carefully, or read the author’s comment, you will find some places where some really visible styles are added to elements that are or may be otherwise transparent. Like ABBR elements or INS or MARK elements.

So this is not a reset stylesheet proper, but more like a base stylesheet that’s 70% reset and 30% set. ;)

Now it does reset a lot of stuff, the most obvious being element margins. I would advise against doing that. I often encounter websites where the CSS coder forgot to style such or such content, some particular content combinations. With resetted margins plus that kind of omission, you end up with chunks of text glued together when they shouldn’t be. Like a header that touches the text above (making it closer to the text it does not describe than to the text it DOES describe). Or blog comments that appear very raw because even though some HTML or Markdown syntax is allowed in comments, the CSS coder only expected raw text in comments.

My point is that the default styles of browsers are useful, and are not as problematic as people often say. There may be like five or six common problems with browser default styles, the rest being very minor issues that may not be covered using a reset stylesheet anyway. Why not just write a base stylesheet that addresses those five or six issues, and be done with it? That stylesheet could be complemented with a few rules for some of the minor problems; those problems generally don’t have a clear-cut solution, so you would need to review what rules you’ll be using for each project, maybe.

The second biggest issue of reset stylesheets is that they apply a bunch of rules to virtually any element in the page. And some of these rules may be inherited. Wich means that a) there is a small performance footprint (maybe/probably? negligible), and b) when you ask Firebug or Web Inspector or IE8’s Developer Tools or Opera DragonFly for the styles that apply to a given element, you get this:

/* START OF EXAMPLE */
selector for this element {
some styles
}
selector for this element’s parent {
some inherited styles
}
html, body, div, span, object, iframe, h1, h2, h3, h4, h5, h6, p, blockquote, pre, a, abbr, address, cite, code, del, dfn, em, img, ins, kbd, q, samp, small, strong, sub, sup, var, b, i, dl, dt, dd, ol, ul, li, fieldset, form, label, legend, table, caption, tbody, tfoot, thead, tr, th, td, article, aside, dialog, figure, footer, header, hgroup, menu, nav, section {
some inherited styles
}
html, body, div, span, object, iframe, h1, h2, h3, h4, h5, h6, p, blockquote, pre, a, abbr, address, cite, code, del, dfn, em, img, ins, kbd, q, samp, small, strong, sub, sup, var, b, i, dl, dt, dd, ol, ul, li, fieldset, form, label, legend, table, caption, tbody, tfoot, thead, tr, th, td, article, aside, dialog, figure, footer, header, hgroup, menu, nav, section {
some inherited styles
}
html, body, div, span, object, iframe, h1, h2, h3, h4, h5, h6, p, blockquote, pre, a, abbr, address, cite, code, del, dfn, em, img, ins, kbd, q, samp, small, strong, sub, sup, var, b, i, dl, dt, dd, ol, ul, li, fieldset, form, label, legend, table, caption, tbody, tfoot, thead, tr, th, td, article, aside, dialog, figure, footer, header, hgroup, menu, nav, section {
some inherited styles
}
html, body, div, span, object, iframe, h1, h2, h3, h4, h5, h6, p, blockquote, pre, a, abbr, address, cite, code, del, dfn, em, img, ins, kbd, q, samp, small, strong, sub, sup, var, b, i, dl, dt, dd, ol, ul, li, fieldset, form, label, legend, table, caption, tbody, tfoot, thead, tr, th, td, article, aside, dialog, figure, footer, header, hgroup, menu, nav, section {
some inherited styles
}
html, body, div, span, object, iframe, h1, h2, h3, h4, h5, h6, p, blockquote, pre, a, abbr, address, cite, code, del, dfn, em, img, ins, kbd, q, samp, small, strong, sub, sup, var, b, i, dl, dt, dd, ol, ul, li, fieldset, form, label, legend, table, caption, tbody, tfoot, thead, tr, th, td, article, aside, dialog, figure, footer, header, hgroup, menu, nav, section {
some inherited styles
}
html, body, div, span, object, iframe, h1, h2, h3, h4, h5, h6, p, blockquote, pre, a, abbr, address, cite, code, del, dfn, em, img, ins, kbd, q, samp, small, strong, sub, sup, var, b, i, dl, dt, dd, ol, ul, li, fieldset, form, label, legend, table, caption, tbody, tfoot, thead, tr, th, td, article, aside, dialog, figure, footer, header, hgroup, menu, nav, section {
some inherited styles
}
html, body, div, span, object, iframe, h1, h2, h3, h4, h5, h6, p, blockquote, pre, a, abbr, address, cite, code, del, dfn, em, img, ins, kbd, q, samp, small, strong, sub, sup, var, b, i, dl, dt, dd, ol, ul, li, fieldset, form, label, legend, table, caption, tbody, tfoot, thead, tr, th, td, article, aside, dialog, figure, footer, header, hgroup, menu, nav, section {
some inherited styles
}
html, body, div, span, object, iframe, h1, h2, h3, h4, h5, h6, p, blockquote, pre, a, abbr, address, cite, code, del, dfn, em, img, ins, kbd, q, samp, small, strong, sub, sup, var, b, i, dl, dt, dd, ol, ul, li, fieldset, form, label, legend, table, caption, tbody, tfoot, thead, tr, th, td, article, aside, dialog, figure, footer, header, hgroup, menu, nav, section {
some inherited styles
}
/* END OF EXAMPLE */

So you get like 90% useless information. Way to pollute the information displayed by those tools.

“What are real advantages of CSS reset?”

Getting rid of the five or six most comment inconsistencies between browser default styles. But any CSS Reset that aims to create a blank state is overkill for that. Then there may be a few projects who NEED a blank state, but apart from some web apps who totally rewrite the look-and-feel and behaviour of most HTML elements they use (e.g. GMail) i think there are not a lot of such projects.

Comment by Web Overhauls at

Thanks for this! Also:

1) Do tables still need ‘cellspacing=”0″‘ in the markup?

2) Great point Martin. As a default, we can use the following file to help remember about the focus:

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

Comment by John Faulds at

I used to use a reset based on Eric Meyer’s but don’t anymore as I found that I explicitly state margins, padding, borders etc on everything anyway, so there was no need to reset everything.

Comment by Rich Clark at

It seems like some of you guys aren’t keen on resets (or base as Florent better describes it). My personal view is that it depends on the project, you have to take each one on it’s merits.

@Florent, some great comments there, thanks for making them. Most of those bits and pieces you picked up having been solved by your’s, Martins and zcorpans comments.

@Web Overhauls, you’ll see from the article that I’ve removed the :focus parts of the stylesheet as people don’t style it so no outline is shown which isn’t good for accessibility. And no, as zcorpan pointed out the cellspacing attribute is deprecated in HTML 5

@John, it’s always interesting to see how different folks work and have a different development path.

Comment by Tony Dunsworth at

I don’t know that it makes a hill of beans, but I made a small adjustment in the reset sheet myself.

Since ins and mark have two common attributes, I just wrote those together and then placed the separated elements on their own.


ins, mark { background-color: #ff9; color: #000; }
ins { text-decoration: none;}
mark { font-style: italic; }

Nothing big, but it seemed logical.

Comment by Rob Miracle at

Couple of points. I think resets are a good idea over all but can be taken to extremes. The reason we need them is to force you to actual define your styles. If blockquote’s margin’s were not reset to 0, there is a good chance that you might like how it looks in firefox and never style it. Opera comes a long and treats blockquotes differently and your design falls apart. So by making all browsers suck the same, as designers we then have to fix it the same. I just wish it wasn’t so heavy and gunk up firebug, but I think its worth it in the end.

Now my main reason for commenting, is I never understood why we kill bullets on unordered lists. I mean I guess my reasoning above could be the answer, but the core functionality of an ul is to expect bullets. I also don’t know why someone decided that bullets should be outside instead of inside. Inquiring minds want to know.

Comment by Sahus Pilwal, Web Designer in Hastings at

I’m of the view that resets at the least achieve more consistent layouts across browsers. I never used them until about a year ago, but find I spend less time hacking, changing position numbers especially to make things work cross-browser! No reset is perfect so must be used on a case by case basis.!

Comment by Florent V. at

“I’m of the view that resets at the least achieve more consistent layouts across browsers.”

How so? There is no black magic in CSS Resets, so the very little they do must help avoid some common problems. So what are those problems? Wouldn’t it be better to teach CSS coders those few common problems?

My take on this is that most developers who use CSS Resets do so because of a) the margin/padding difference for the BODY, UL and OL elements, and b) lack of understanding of the collapsing margins mechanism in CSS.

Comment by Rich at

@Tony, we certainly could combine the selectors as you’ve done in order to save a few bytes (and repetition) however I’ve left it like that to make it easy for developers to see what’s going on and amend as required.

@Rob Miracle, it’s true that you might like how the browser renders a blockquote in some browsers but not others, however I doubt that they’ll be sharing common default stylesheets in the near future. Also on your point re bullets, you’ll notice that that’s why I’ve only removed bullets from ul’s that are within the nav element.

@Hurr, good spot, should be corrected now.

@Sahus, you’re spot on about using resets or base files on a case by case basis, and that’s why I urge you to take it and modify it for your own needs.

Comment by Sunny Singh at

I was actually surprised how many people disliked resets, or at least were not in love with them as many others. In fact this post should’ve been called “Resets, like em or hate em here’s one for HTML5.”

Florent pointed out that it was only 5 or 6 inconsistencies, and I really disagree. Before resets, I used to have to zero out margins and padding on many elements, which was really annoying. Then when there’s layout problems (especially for IE), instead of doing just margin-left or martin-top etc, I would have to use the shorthand to zero out all the margins/padding that I didn’t zero out in the first place. Also when you don’t really know or remember what margins you set in the first place, then you don’t want to be zeroing them out or setting the same margins again on page specific css and such and to work out bugs.

I have never had the Firebug problems of which Florent talks about, although I see your point. However, when you set css for elements, it overwrites the reset (which should be before any other css in the file or page). So what you see first is the id, class, and the most specific css to it first. Then you will start seeing the styling for general tags, which you can skip and not have to read at all. So that is definitely not a problem, and the reset does not appear a billion times like you’ve posted.

Sahus is pretty much right on here though, it prevents layout issues. With my reset (which I’ve formed from Eric Meyer’s and YUI’s for fonts), I rarely have to go in browsers to check for inconsistencies. IE might have some, but at least I know that a negative margin here and there will solve it instead of wondering what default properties it has set on my element.

If your coding is not so hectic without a reset, that’s fine with me. I just however think a css reset will benefit in many ways, including helping you code less and much faster due to less bugs within browsers and even Firefox itself if you’re looking to creating a complex site.

Awesome HTML5 reset though, I probably will be sticking to XHTML for a while still, but I will start experimenting soon like YouTube has on http://www.youtube.com/html5

Comment by Florent V. at

“Florent pointed out that it was only 5 or 6 inconsistencies, and I really disagree.”

Then could you maybe list more than 10 such inconsistencies? I’m not speaking of CSS rendering bugs in some browser (mostly IE 6-7), but of cases where one HTML element has significantly different default styles in different browsers. Obviously even with the same default styles, one browser could still mess up the rendering, but that’s not an issue relevant to CSS Resets. ;)

Here is the list i can come up with:

1. The BODY element has a 8px margin in some browsers, and a 8px padding in some others. If you want to be able to have DIVs or other elements touch the borders of the viewport, you will need a body {margin:0; padding:0;}

2. The UL and OL elements have a 40px space on the left. That space is either a padding-left or margin-left, depending on the browser. When you want to zero out this space, you have to specify margin-left:0; padding-left:0.

3. The top and bottom margins of the P and H1-6 elements are 1em in most browsers. But some may be using a pixel value instead (i think IE does, but i can’t guarantee that and i should test it). Setting p {margin: 1em 0;} is enough to avoid most inconsistencies, since for titles you’re very likely to give them precise margins when you end up styling them.

4. Default margin and padding for the FIELDSET element is a bit inconsistent from one browser to another. Setting fieldset {margin: 0; padding: 0;} is enough to fix this problem. Or you may choose to fix it when you end up using a FIELDSET element (which doesn’t happen that often if you know your HTML).

5. The exact font-size for H1, H2, H3 elements is slightly different between IE and other browsers. Nothing major, but if you rely on the default font-size for your title you may have slight inconsistencies. I tend to style the global font-size and titles font-sizes at the very beginning of a project, avoiding that kind of issues.

I can’t think of anything else from the top of my mind (and i have a rather comprehensive knowledge of CSS).

I’m not saying that CSS Resets are not useful to some extent. I think it’s pretty convenient to have a base stylesheet that will 1) take care of the five issues i have listed above, 2) maybe correct the default styles (such as recommended by the W3C spec) to get something closer to what we usually need in most projects (smaller overall font-size and smaller title font-sizes, for instance), 3) provide a canvas that we can then alter to further define the basic styles for a given project. But classical CSS Resets (and this one as well) take a heavy-handed AND UNNECESSARY approach to (1) and (2), and don’t provide a canvas that coders can alter. Which is why i think they are inferior to a well thought-out base stylesheet.

Granted, the negative consequences of a classic CSS Reset are no big deal. It’s mostly coders forgetting to set some styles, and the pollution of {{your favorite tool here}} results when inspecting an element’s styles. Let me illustrate both issues:

- http://files.getdropbox.com/u/145744/screens/troublewithreset.png
- http://files.getdropbox.com/u/145744/screens/reset-inheritance.png

(Protip: if your reset stylesheet does not specify an inherited property for all elements (no font-size or color…), you avoid that second issue altogether.)

Here is the base stylesheet (and some extensions) that i use in my projects, and that i publish in a set of tools for Komodo or on Alsacreations.com (website on web standards and mostly front-end development). When i use it in a project, i usually strip out most of the comments, and i may not use all the rules.

http://dpaste.com/hold/74038/

“So that is definitely not a problem, and the reset does not appear a billion times like you’ve posted.”

That example was an extreme case, but it was NOT an exaggeration. See the screenshot i posted above, or inspect any element (deep enough in the DOM tree) on this website. (Just checked right now on the “Comment by…” line on this page. The actual result is MORE complex than the example i gave in a previous message. The added complexity is that if you want to see what the styles inherited from BODY are, you have to scroll past five blocks of bla,bla,bla,bla,bla,bla,bla{font-size:100%;), which is worse than what my example showed.)

I’ll end this comment with a question: do you understand the concept of collapsing margins well? Do you know what it is? Are you able to tell, when coding, if it will apply or not?
I’m asking this because in my experience i have found that many people insisting on the usefulness of CSS Resets don’t know about collapsing margins or know a bit but are reluctant to deal with them.

Comment by Entheogen at

Shouldn’t there just be a simple CSS-tag or something that kills the default (or all) styles in every browser? That would be a nice option.

Comment by John Faulds at

I just however think a css reset will benefit in many ways, including helping you code less and much faster due to less bugs within browsers and even Firefox itself if you’re looking to creating a complex site.

As mentioned before, as someone who used to use a reset, but now who doesn’t, I find the opposite to be the case.

Shouldn’t there just be a simple CSS-tag or something that kills the default (or all) styles in every browser? That would be a nice option.

You can use * { margin: 0; padding: 0 } but if you read the original article by Eric Meyer on resets linked near the beginning of the article, you’ll see why that method has its problems.

Comment by Sunny Singh at

In response to Florent again, I think this debate on whether using a reset or not is kinda pointless however I do see your point.

I wish I could name out about 20 problems right off the top of my head, but I really can’t but having default margins and padding on every tag, consistent font sizing, table display properties (border-collapse), and other small things like text alignment on everything that I begin making.

Here’s the differences I see on resets,

If using a hard reset, you will never have to reset anything but style things accordingly. I don’t believe you should set list-style to none on default, but your reset will back you up on future pages and sites. For me, it’s simply the assurance of having a reset, otherwise I find myself spending lots of time wondering why something’s not the same in every browser. Font sizing is a big one, but I’ve taken a look at my own reset and I’ve noticed that you’re completely right on there being not a lot to reset or many styles, but this chunk of code in my core css file has everything built on it, for the stuff it does reset. With reset margins, I know that if I put margin-left: 5px; I will ONLY get 5 pixels of margin on the left. No defaults on the top or right or any of that. What’s the best way to do that? Simply zero out margins in a big reset with tags separated by commas. Any defaults I do agree with are how font-weight and font-style are set on heading, strong, and em tags and probably a couple more. Mostly anything visual, but not structural. I feel it’s pointless to set defaults for that, since the main purpose of them is to have some sort of visual cue that it’s important. Now let’s say not every page of your site uses the template you set up in your base.css file, not having a reset you cannot just load your core css or copying and pasting the reset you usually use. I really don’t know if you’re resetting things on #header or divs in general, but a big file like that doesn’t seem necessary just to remove some padding or borders.
My css file is located over here: http://cdn.myunv.com/css/uecore.css which has my reset and also has my template styles so it actually is a “base.css” file however I just like the name core more. If I only needed the reset though, I could simply append a ?reset=only to the url since my css is a php file in disguise but copying and pasting is a better option. I usually find having to use this on simple pages though without the template, where a hard-core reset sometimes isn’t necessary. Besides, I’m working on having a consistent template on every page anyways.

When just having a good “base.css,”

I am not sure if what you mean by a good base.css file. Are you having some sort of small reset then, because it will still not turn out the same. I don’t like default margins/paddings on anything, and have had so many bugs with that so I am sort of afraid of how inconsistent browser styles are. Now if are resetting just margins and padding and perhaps font size on body (and inputs, tables, pre type tags..) then you will still see yourself having a ton of tags reset which doesn’t exactly separate you from not using a reset or a so called “hard” reset. If you don’t use one, I couldn’t imagine how many “margin: 0; padding: 0;” you would have, and all those separate resets will add up to the file size (every bit counts, I even code in single lines).

Now the reason I’ve called this debate pointless is not to be mean but considering I have yet find any browsers problems that have come from eric meyer’s reset, have not yet had debugging issues where the resets get in the way in Firebug, and I have come from not using a reset at all or a bare reset to using a good one where now I feel like I code so much less now with more browser compatible pages (I’m not talking about IE6, however I was surprised to how some stuff actually did work for it). In your case you’ve come from using a reset to not using one, so having yet to see the advantages to not using one (or having not seen disadvantages of using one), I really don’t think I’ll be cutting out support for CSS resets.

I hope not to stir up anything here, I simply believe people should use resets because it works for me. I can exactly see why some may not prefer it or even use it at all.

Comment by Florent V. at

I don’t see this debate as pointless. Although it could be seen as nitpicking.

I’m actually interested in why people would FEEL that a CSS Reset is necessary or vastly useful. I have used very basic reset styles (like * {margin:0; padding:0;}) as a beginner, because that technique was recommended on many ressources. But i quickly found that having to redefine everything was a pain, and stopped using reset techniques altogether.

I welcome decent reset stylesheets such as this one or Eric Meyer’s work. I mean, if people want to use a reset stylesheet then that stylesheet should at least avoid major problems (keyboard accessibility, OS styles on form elements, etc.).

“I don’t like default margins/paddings on anything, and have had so many bugs with that so I am sort of afraid of how inconsistent browser styles are.”

Were the bugs you had really about default margins and padding? I’m not sure about that. See, i’ve made my point about reset stylesheets and base stylesheets, you made your point about why you think like using a reset stylesheet, but now the one thing i’m interested in is: why do you (and others) FEEL that default margins and padding wreak havoc? I have a hunch about that, so allow me to repeat my questions:

Do you understand the concept of collapsing margins well? Are you able to tell, when coding, if it will apply or not?

Those are two simple questions; you should be able to answer “yes” or “no” to each question. If you don’t mind, i would like to know if you (or any person who relies on some kind of reset stylesheet) master that CSS concept or not.

Comment by Sunny Singh at

Default margins and padding don’t wreak havoc, they are simply annoying to zero out especially for divs. One major use I had in having a reset for margins/padding is the whole point of “cascading” style sheets. If you set margin-top: 50px; then everything else will be zero which is what I want. In most cases I don’t see a use of default margins, on a blog it might make sense but I usually set padding on paragraphs with text-indent, and just a margin-left on headings.

For your next question, I usually do see problems like these but they are not a problem. I solve them with padding, perhaps a wrapper, or relative positioning with top and left. Depending on the situation, there is always a way to position or add spacing properly. The box model is the first thing I learned about CSS, so over time I have become experienced in being able to position anything to my liking. With a reset, I would find myself with all these default values I simply don’t need. This is mostly just margin and padding, so not having a reset for them does not make sense.

You have opened a pretty interesting topic for me to think about though, are css resets needed or are they there just to make you feel good about your css? Well I think they are needed to an extent, I use Eric Meyer’s reset and Yahoo’s font reset. Did I ever have problems with this? No, and if I did I learned more about CSS this way.

Here’s an interesting story though. I had to remove my reset because it was causing problems on a community site that I have on Flux, but I have it wrapped in my template. It had nothing to do with display options, but it cause a weird lag. Maybe some JavaScript file kept defining stuff or something. Anyways I removed my reset, and what do you know? Only the header had a few problems. I setup php so if it had ?id=community appended to it, it’d comment out the reset but for every other page it’d still show.
So from that I learned that my template won’t break if I don’t have a reset, and in fact it’s probably from my XHTML that led to the page not breaking still. However, I feel better with it, have to code less margin 0s, had no problems with it so far and lots of people recommend it.

Comment by Arlen at

As long as we’re nitpicking, I found it interesting Florent said he could only come up with 5 differences, as he listed 14 differences in the way elements were styled by various browsers (differences between h1-h6 renderings count as 6 differences, because they’re six different elements, after all).

As for resets, I use them after a fashion. I began by using Meyer’s reset as it was written, so I’ll start from there. Why did I use it? Certainly not because of lack of understanding. I’ll be honest, I used it out of laziness. Using it, I had a known, established base to start styling from. Oh, I could have coded on without it, pulling the default numbers each browser used from my memory, covering all the exceptions myself as I wrote (and going back to diagnose and fix the occasional times I missed — hey, nobody’s perfect) but just plugging in the reset saved me both effort and time, and time is money. And as for the “polluted” firebug displays, after working the reset into my normal workflow I had less occasion to need firebug in the first place, so I broke even on that.

But I said “began by.” I don’t use it straight-up any more. Instead, I go into it and change the neutral values to whatever I want the defaults for the project to be. For example, I might want the default margin-left on a ul to be 1.5em, and the default for a ul inside a nav block to be 0. So those entries will get made in the default stylesheet I use for the project. I have a set of “house defaults” now that form the base for projects, with slight changes from that as required.

I still find the principle of a reset valuable, because it saves effort and time and forestalls many of those “dumb mistakes” (which, like spelling errors, happen and require time to go back, locate, and fix). I just don’t see a need to reset to a neutral value before setting to a “real” one.

Comment by Steven tate at

Hey All.

Just a quick note about the reset ….

Adding padding: 0; to an ordered list tag causes the numbers to not be written. Sorry if this has already been mentioned here. Comments have gotten out of control on this post. Maybe because this blog ROCKS.

Anyway, what does reset mean for an ordered list tag? Would we want to kill numbering?

What ya think?

Steven Tate

Comment by Rich Clark at

Hi Steven

Good point about the numbering being lost with the padding, I think I’ll make that change.

Re killing numbering, you’ll see I’ve only taken the list-type off of those ul’s within a nav element (unlike Eric’s original) so numbering shouldn’t be affected only the padding.

Cheers

Comment by Hikari at

strike was deprecated too? well, I always used del anyway

An off-topic question: what will we do with the deprecation of u (underline) element? I’ve read ppl saying that only links should be underlined, but I don’t agree because we always had the trio bold-italic-underline in text editors. It seems we’ll have to use span with text-decoration attribute, but it is much bigger than ‘u’.

I also forgot to ask about abbr. Should we use it on EVERY abbreviation on our site, for accessibility sake?

If it is true that padding:0 hides ol numbers, it would be better to give it a default style that includes numbers. CSS Reset must not mean that everything will be removed and then restyled (I’ve even read that strong must have bold removed!). It is just a way to ensure browser defaults are overwritten so that differences in browsers defaults don’t make ours sites look different on each of them. It shouldn’t mean that we must remove elements default look & feel.

W3C should suggest a default style to finish these problems :p

Comment by Hamranhansenhansen at

> CSS Unreset (aka base stylesheet)
> So this is not a reset stylesheet proper, but more like a base stylesheet

The semantics you’re using are completely meaningless. Base or reset, call it what you will, the point of it is to smooth out the differences in various user agent (browser) stylesheets. You could call it “smooth stylesheet” or “neutral stylesheet” it doesn’t matter. However, for some years now, the Web development community has been calling these “reset stylesheets” because that’s what Eric Meyer called them in his widely-read book on CSS.

If you make a site that is completely devoid of any CSS, it will still have a stylesheet applied to it by the browser. That stylesheet comes first in the cascade. If you make only one more stylesheet, the page will look different in each browser because in Firefox you are seeing the Firefox stylesheet plus your stylesheet, and in WebKit you’re seeing the WebKit stylesheet and then your stylesheet. If you put a reset stylesheet in-between the user agent stylesheet and the site stylesheet, then the reset gives you a common base to work from that is independent of various browsers.

Ideally, there would be no need for an HTML5 reset stylesheet because the spec covers browsers also, and defines how each browser should apply a user agent stylesheet in a standard way, however not all browsers are up to the spec yet.

In practice, a reset stylesheet makes it easier to treat an HTML page like you are working in a layout program instead of a word processor. You ask for 5em of space and you get it, not 4em instead because some element already has a 1em margin.

It feels intellectually satisfying to know all the default margins and which browser messes up what, but there are so many ugly, ugly pages on the Web, the priority should be the creative satisfaction of making solid, readable layouts. There is still a movement in Web design to use tables for layout because CSS can be so easily overcomplicated. Anything that makes it easier to go from zero to a great-looking page in all browsers should get strong consideration.

Comment by Florent V. at

The semantics you’re using are completely meaningless. Base or reset, call it what you will, the point of it is to smooth out the differences in various user agent (browser) stylesheets.

I disagree. Yes, there is a common goal, but i have presented two different takes on that “smooth out the differences” goal. One is the classic Reset stylesheet, which zeroes out everything it can. Another one is trying to stay close to the browser’s default styles, while rounding a few angles (figuratively). You can mix the two (my own “base stylesheet” is roughly 80% base and 20% reset), so the differences are not absolute. Still, i think that the distinction is far from meaningless, though it may be of more importance to specialists (front-end developers) than to occasional CSS coders.

Comment by Reset CSS para HTML5 at

[...] para eliminar diferencias entre navegadores desde el principio. Pues ahora os traemos de la mano de html5doctor.com un nuevo reset CSS adaptado a HTML5. Incluye las nuevas etiquetas y elimina las que ya no [...]

Comment by Michael at

The point of these reset stylesheets is to generally get everyone on the same track and to encourage progressive design while still supporting aged, or poor browsers.

You might even consider adding

body { font-size: 75%; }

to make the base text size 12px (which I personally feel is a little small) or alternatively

body { font-size: 62.5%; }

for 10px

Either or.

Comment by Hikari at

I’ve finally started developing a Wordpress theme from scratch from my sites and I used your HTML5 Reset for it. I’ve done some changes and I’d like to share them with you.

1) I removed ul, ol and li from that first blob of resets. Leaving them there had broken nested lists, they were being shown all with the same margin, as if they were 1 unique list, and with no list-style-type. It would take too work to restyle nested margins with different list-style-type for each nesting, so instead of turning everything to 0 I copied FireFox’s default style, which seems to be very complete.

Interesting that together with ul and ol, FireFox also styles dir and menu with them, and sets it all perfect.

2) I know about deprecated HTML4 elements, but still people may use them. I know that FCKEdit uses strike instead of del, and also people may still have <u> around.

Talking about <u>, I’ve found a nice replacement for it. A simple .ul class setting text-decoration:underline is the obvious replacement. But instead of using it with a span, I’ve defaulted it for em, so that when they are together italic is replaced for normal and underline is set.

That’s nice because underline is meant for emphasing a text, so nothing better for Semantic purposes if em is used, together with a class, for underlining too.

3) I’ve also removed <q> resetting, setting default content and quotes for it. I know HTML spec says each language should have their specific quote… maybe somebody could share a full list of laguage quotes so that we can add to our reset :P

In general, I don’t like the idea of CSS Reset cleaning everything. CSS Reset should be meant for resetting browser inconsistent defaults, setting our default over them… and not for resetting styles themselves.

Comment by Hikari at

Ah! 1 more thing.

Bringing strike and u back still validated it over CSS 2.1, so I don’t think those elements should be excluded just because the reset is meant for HTML5.

Let HTML5 validators ding users that still use those elements! Let’s not mix markup matters with styling matters… If we ommit them, what will happen in practice is that they will be styled by browsers defaults, which is what we wanna avoid with CSS Resets to begin with.

If we wanna use styling to blame invalid HTML5 elements, it would be better to set some odd styling to them, like a background-color that would highlight where they are :P

Comment by Tyler Rasmussen at

I did my best, but that just adding:

article,aside,audio,canvas,datagrid,datalist,details,dialog,figure,footer,header,hgroup,menu,nav,section,video{display: block;}abbr,eventsource,mark,meter,time,progress,output,bb{display:inline;}

Comment by Paul Irish at

In my experience adding a zoom:1 to the new elements style made IE6 especially play much much nicer.


article, aside, dialog, figure, footer, header, hgroup, nav, section {
display:block; zoom:1;
}

Comment by 3streamer blog - HTML初心者が知っておくべきリセットCSS と3つのポイント at

[...] HTMLの次期バージョンHTML5の策定作業が進行していますが、既にHTML5のタグやCSS3を先行実装するブラウザも現れてきました。これらが実際の制作現場で使われるようになると、また制作の手法も変わってくるでしょう。リセットCSSもHTML5用のものが提案されていたりします。今後どうなっていくのか注目です。 [...]

Comment by Richard Clark at

@Tyler, why would that need adding specifically? Elements are treated as inline by default anyway and some of those in your list should be treated as block so it would be bloating the code unnecessarily.

@Paul, cheers for that Paul. I don’t think I’ve come across many problems with IE6 except the usual bugs such as giving elements hasLayout as you’ve pointed out. I would probably add zoom:1 to my default IE6 stylesheet.

Leave a Reply

You can use these tags: <a href="" title=""> <abbr title=""> <b> <blockquote cite=""> <cite> <del datetime=""> <em> <i> <q cite=""> <strong>

You can also use <code>, and remember to use &lt; and &gt; for brackets.