meyerweb.com

Skip to: site navigation/presentation
Skip to: Thoughts From Eric

Reset Revisited

It was close to four years ago now that I first floated (ha!), publicly refined, and then published at its own home what’s become known as the “Eric Meyer Reset”.  At the time, I expected it would be of interest to a small portion of the standards community, provoke some thought among fellow craftspeople, and get used occasionally when it seemed handy.  Instead, it’s ended up almost everywhere.

(This occasionally backfires on me when people use it in the CSS of e-mail campaigns, it’s exposed by older mail clients, and people then mail me to demand that I unsubscribe them from the mailing list.  But that’s not the worst backfire—I’ll get to that in just a minute.)

Four years is long enough for a revisit, I’d say.  I spent a little time working on and thinking about it over the holidays.  Here’s where I ended up.

/* http://meyerweb.com/eric/tools/css/reset/ 
   v2.0b1 | 201101 
   NOTE: WORK IN PROGRESS
   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, figcaption, figure, 
footer, header, hgroup, menu, nav, section, summary,
time, mark, audio, video {
	margin: 0;
	padding: 0;
	border: 0;
	outline: 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;
}

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

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

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

Some of you may be thinking: “Hey, it’s the HTML5 Doctor reset!”  Actually, no, though I did use their work as a check on my own.  I felt like that one went a bit far, to be honest.  What I have above is simply the reset I had before with the following changes:

  • Removed font from the selector of the first rule.  It’s been long enough now, I think.  We can let that one go.
  • Removed background: transparent from the declaration block of the first rule.  I don’t think it really served any purpose in the long run, given the way browsers style by default and the CSS-defined default for background-color (which background encompasses, of course).  Its removal will also stop causing table-appearance glitches in old versions of IE, if that’s of interest.
  • Added font: inherit to the declaration block of the first rule.  There are still older versions of IE that don’t understand inherit, but support is now widespread enough that I feel this can go in.  I left font-size: 100% as a sop to older browsers, and override it with the next declaration in those browsers that understand.
  • Added HTML5 elements to the selector of the first rule.  While this is probably unnecessary right now, those elements being about as styled as a common div, it’s in the spirit of the thing to list them.
  • A separate rule to make blocks of those HTML5 elements that generally default to blocks.  This is more backward-looking, as the comment suggests, and it’s a prime excision candidate for anyone adapting these styles to their own use.  However, if you’ve ever known the pain of HTML5 markup shattering layouts in, say, older versions of Firefox, this rule has a place.
  • Removed the “cellspacing” comment near the end.  It used to be the case that lots of browsers needed the support, but that’s a lot less true today.
  • And then the big one, trying to correct the biggest backfire of the whole enterprise: I commented out and subtly altered the commentary on the :focus rule without removing it entirely.

On that last point, defining an invisible focus was the biggest blunder of the original reset.  In hindsight, it’s really a obvious unforced error, but when I published the reset I literally had no conception that it would be just copied (or, worse, hotlinked) blindly in a thousand sites and frameworks.  As the new advocacy site outlinenone.com points out, I did say right in the style sheet that one should define a focus style.  I put in a value of 0 in the same spirit I zeroed out paragraph margins and set the body element’s line-height to 1: by taking everything to a “plain baseline”, the thoughtful craftsperson would be reminded to define the focus style that made most sense for their site’s design.

Instead, focus outlines were obliterated wholesale as lots and lots of people, not all of them craftsmen, just copied the reset and built on top of it without thinking about it.  I can’t find it in my heart to fault them: most construction workers don’t think about how beams and rivets or even riveters are made.  They just bolt ‘em together and make a building.

Perhaps some of the pain would have been eased if I had said in the comment, as I do now, “remember to define visible focus styles”.  But I doubt it.

So in this revision, I’ve altered the rule and commentary to raise its visibility, but more importantly I’ve commented out the whole rule.  This time, copiers and hotlinkers won’t destroy focusing.  Some may still uncomment it and change the value back to 0, of course, but that could happen anyway.  With luck, this change will help educate.

As was the case in 2007, comments and suggestions are most welcome, and may well result in changes that make it into the final version.  Also, my thanks to the HTML5 Doctor crew for publishing their variant, which I used as a sanity check; and Michael Tuck, whose research into the history of resets got me looking back and interested in moving things forward.

Addendum 3 Jan 11:  as the previous paragraph says, and the version number (2.0b1) heavily implies, this is not a final version.  It may well change, either due to errors on my part (one of which has already come to light) or changes of mind due to discussions in the comments.  You can take this version and use it if you want, but I don’t particularly recommend it because—again—changes are likely.

Translations

79 Responses»

    • #1
    • Comment
    • Mon 3 Jan 2011
    • 1559
    Leonardo Picado wrote in to say...

    Thanks a lot Eric. One question which versions of IE do you consider “older versions”? 6 and lower?

    • #2
    • Comment
    • Mon 3 Jan 2011
    • 1612
    Eric Meyer wrote in to say...

    Definitely IE6 and earlier, Leonardo, and here I’m also referring to IE7 with regards to inherit, which IE7 didn’t really support.

    • #3
    • Comment
    • Mon 3 Jan 2011
    • 1612
    Alan Bristow wrote in to say...

    Used the last one with minor tweaks*, I’m sure I’ll upgrade to this revision. Much appreciated, thanks Eric.

    *I think I forced STRONG and EM in H1-H6 to work, rather than not, from memory…

    • #4
    • Comment
    • Mon 3 Jan 2011
    • 1620
    Peter wrote in to say...

    Thank you, I appreciate this change a lot.

    I can only hope Dan, other Dan, Jeffrey, Jason and other legends are willing to update their stylesheets so that thousands can follow.

    • #5
    • Comment
    • Mon 3 Jan 2011
    • 1621
    Karl Laurentius Roos wrote in to say...

    Thank’s Eric. Compressed and now residing in my code clips!

    • #6
    • Comment
    • Mon 3 Jan 2011
    • 1637
    Paul Irish wrote in to say...

    Very nice. Classy changes and a refreshed new look.

    However, all anchor’s (focused or not) are still getting an outline:0 thanks to the first declaration.

    I worked with Rich at HTML5 Doctor to have the <a> tag dropped from the selector of the first block, so it wouldn’t remain de-outlined. You might want to consider the same.

    • #7
    • Comment
    • Mon 3 Jan 2011
    • 1643
    Ryan wrote in to say...

    Thanks Eric, for revisiting this.
    It is funny to see you talk about how the reset began, four years ago thinking a few would check it out, and now having it dubbed by your name. ;)
    Must be kinda cool in some respects though eh?
    Thanks again!

    -Ryan

    • #8
    • Comment
    • Mon 3 Jan 2011
    • 1654
    Eric Meyer wrote in to say...

    Karl, you might want to re-read the first sentence of the last paragraph before you go clipping this.

    Paul, doh! I originally meant to remove a from the first rule entirely, then changed my mind but forgot about that particular interaction. Um, I blame the egg nog. Will have to cogitate further and decide where to go from here.

    • #9
    • Comment
    • Mon 3 Jan 2011
    • 1718
    Cogito wrote in to say...

    I don’t know why people make a big thing out of the whole outline issue. I mean, a builder might not know how beams and rivets are made, but they can see the holes in the beams and know that’s where the rivets go… Any designer worth his/her salt should be able to identify the need for an outline and not be a lazy monogloid about it.

    Good work, by the way. I like Mr Clark’s reset so the similarity is good. :)

    • #10
    • Comment
    • Mon 3 Jan 2011
    • 1740
    • #11
    • Comment
    • Mon 3 Jan 2011
    • 1748
    Peter Wilson wrote in to say...

    I usually comment out the list-style reset as it gets a bit messy when redefining them. I’ll still define the margin and padding for li to keep it consistant cross browser.

    I’m not sure if this is the best place for this but I think it worth mentioning. When defining the :focus style, I usually reverse the back and foreground colours to highlight focus as much as possibile.


    a:link, a:visited {
    color: blue; background: white; text-decoration: underline;
    }

    a:focus {
    color: white; background: blue; text-decoration: none;
    }

    a:hover, a:active {
    color: blue; background: white; text-decoration: underline;
    }

    The back and foreground colours need to be defined repetitively to avoid problems when an element has both focus and hover, but the extra code is a small price to pay.

    • #12
    • Comment
    • Mon 3 Jan 2011
    • 1757
    Alex wrote in to say...

    Hey Eric, I have run into an issue sometimes where webkit browsers are still able to overwrite the reset on margins of an unordered list with their own browser defaults. Have you seen this before? Is there something wrong with my own reset? I can’t imagine having an issue copying the block…

    Thanks!

    • #13
    • Comment
    • Mon 3 Jan 2011
    • 1806
    Carsten wrote in to say...

    I don’t understand why you assign

    font-size: 100%;
    vertical-align: baseline;

    to sub and sup.
    Maybe you could remove them from the first block and add a second one with

    sub, sup {
    margin: 0;
    padding: 0;
    border: 0;
    outline: 0;
    font: inherit;
    }

    Or am I wrong?

    • #14
    • Comment
    • Mon 3 Jan 2011
    • 1818
    Grant Husbands wrote in to say...

    That’s an lot of rules to be applied to almost every HTML element, which visually clogs DOM inspectors (which is one of my reasons for rarely using these styling resets).

    I think it would be better to be more specific for at least some of them. Do we really need all those rules on every div and span? Isn’t font inheritance only ever broken for tables and form controls (and only changed by default for a few specific presentational tags)?

    Maybe a better solution would be for DOM inspectors to be modified to not show rules that have no effect on the page display, but that won’t happen in IE9 or lower.

    • #15
    • Comment
    • Mon 3 Jan 2011
    • 1823
    Ricardo wrote in to say...

    Nice to see background-color go.

    Anyone knows exactly which browsers still need cellspacing=”0″ nowadays? I’m on vacation so I don’t have any windows PC around. If IE7 is on the list I’d be wary to remove the warning, as it will help make it the new IE6 :)

    • #16
    • Comment
    • Mon 3 Jan 2011
    • 1834
    Shane wrote in to say...

    I have nothing to add but I think it is great that you have released another update to this somehow legendary piece of CSS!

    To be honest, I too was one of those that for a long time did not realise you had to have a :focus for keyboard users. I never liked the default outline so I have since changed it for any design focal points, such as the navigation, to be more or less the same as :hover. Does anyone see any accessibility problems with that?

    • #17
    • Comment
    • Mon 3 Jan 2011
    • 1844
    Danz wrote in to say...

    This is a much more precise reset stylesheet I have seen in a while. Kudos for your revision. However I do agree with @Carsten regarding sub, and sup it should be removed from first block due to the nature of the element. Having the vertical-align override the default makes it pointless, and harder to redefine later in the stylesheet.

    • #18
    • Comment
    • Mon 3 Jan 2011
    • 1851
    Jeremy Hixon wrote in to say...

    I used the previous reset a lot, but I used it as more of a starting point than a set style. Lately, though, I had switched to using the HTML5 version because of my use of the basic HTML5 elements in my projects. But, now, I can go back to using what I consider the source. Thanks for picking it up again.

    • #19
    • Comment
    • Mon 3 Jan 2011
    • 1925
    Evandro Oliveira wrote in to say...

    Peter (@ #11 comment) Anchors and any other inline element should have ‘transparent’ background, not white.

    • #20
    • Pingback
    • Mon 3 Jan 2011
    • 2055
    Received from Around the Web: Nike’s World, URL Design, & facto.Me’s First 50 hrs | Think Vitamin

    […] "must read." Reset Revisted by Eric […]

    • #21
    • Pingback
    • Mon 3 Jan 2011
    • 2101
    Received from Eric Meyer revisits his famous browser reset | Every Day is a CSS Kind of Day

    […] Eric’s Archived Thoughts: Reset Revisited This entry was posted in CSS, HTML5. Bookmark the permalink. ← Benchmarking jQuery selector performance […]

    • #22
    • Comment
    • Mon 3 Jan 2011
    • 2253
    Matt Thomas wrote in to say...

    Thanks Eric! I’m a long time fan and have always found your work very insightful. One small addition that I always add is html{overflow-y:scroll} to prevent the page from shifting horizontally. It’s debatable as to whether it is a reset or not, but useful none the less.

    • #23
    • Comment
    • Mon 3 Jan 2011
    • 2313
    Brian LePore wrote in to say...

    While I agree with Evandro’s comments about inline elements, I really do plead that background: #fff; be added to the body element. Since this is very likely to be caught up by many people, just like the first one was, I feel the need to point out that the number of Web sites that assume a background color of white is legion, and these are the same sites that are likely to just link to the CSS reset file. The sites that don’t need it will have set it to what they want, while fixing many sites that forgot all about it (and let us not say that this only happens on small sites as I’ve come across sections of ebay and google that don’t have a body bg color set).

    • #24
    • Comment
    • Tue 4 Jan 2011
    • 0704
    Russell Bishop wrote in to say...

    Very interesting read around the justification of certain changes. I’ll wait for a solid release before I update ours (we’ve added to it over the years).

    • #25
    • Comment
    • Tue 4 Jan 2011
    • 0735
    Scott wrote in to say...

    I completely agree with Grant Husbands about the first rule. Which browsers are setting margin, padding and border on div and span elements? Not one I’ve ever used, that’s for sure. Same goes for the various inline elements.

    I also wonder, what’s the point of resetting everything to an unusable baseline (e.g. paragraphs/lists/headings with no margin) only to go and set them later on in your stylesheet. IMO it would work much more effectively to set some standard values, that developers can change if it suits.

    • #26
    • Comment
    • Tue 4 Jan 2011
    • 0757
    Zielun wrote in to say...

    You wrote that your goal was to take all body elements to “plain baseline” but do you really think that sub and sup elements should be treated the same way as other inline elements?

    Thanks for your work btw.

    • #27
    • Comment
    • Tue 4 Jan 2011
    • 0809
    Adam Messinger wrote in to say...

    Thanks for this. I’ve been using a customized combination of your earlier reset and the HTML5 Doctor reset. I’ll be taking a look at this latest release and incorporating the changes that make sense for my work.

    • #28
    • Comment
    • Tue 4 Jan 2011
    • 0850
    prisca wrote in to say...

    Eric, just to say thanks for your continued work on this –
    very, very useful, especially whenever I teach a bunch of new web designers ;)

    It does make me smile though that you didn’t expect it to be used so widely ~ where else would we go for guidance and reference ;)
    thanks again, your code and writing is much appreciated, as always.

    • #29
    • Comment
    • Tue 4 Jan 2011
    • 1119
    Ben wrote in to say...

    Hello Eric, I wanted to thank you for this CSS reset. I end up on your website everytime I start a new project!

    I thought it would be convenient to have a compressed version of the reset on this very page, do you mind if I post it in the comments ? (Comments and credits would be stripped out for better performance)

    Kind regards,
    Ben

    • #30
    • Comment
    • Tue 4 Jan 2011
    • 1159
    Ryan wrote in to say...

    Passed this on to some coworkers: these were some of the collective responses, I am curious what your take on these are?

    the first set, since almost every html selector is listed anyway, save some filesize and just use
    * {margin:0;…}

    border-collapse:collapse on causes overall table width issues and cells that utilize colored borders

    list-style:none on defeats the purpose and use of an ordered list.

    font-size:100% on everything not sure what this really accomplishes because there isnt a baseline size on either body or html to compare 100% against?

    • #31
    • Comment
    • Tue 4 Jan 2011
    • 1231
    Florent Verschelde wrote in to say...

    Nice revision. I’m still not a fan of CSS resets — see Should You Reset Your CSS? for some reasons — but it’s nice to have a good reset stylesheets for projects where teammates insist on using one.

    I should probably revise my base stylesheet (which I playfully called “No Reset”) to iron out some issues, and maybe write a redux version.

    • #32
    • Comment
    • Tue 4 Jan 2011
    • 1237
    William wrote in to say...

    To further the construction worker analogy, most painters don’t think about how colors are chosen on a construction site or why, e.g. why is it #800080 and not #551a8b, and why is it #00e and not #00c? So, in order to take everything to a plain baseline, I’d offer that you’d need to reset the link specificity colors as well. It’ll serve the same educational purpose as guiding them to “remember to define visible focus styles”.

    The down side to all this is that your reset.css ain’t been copied and propagated over the last near 4 years directly from your site. Front-end code gets copied, pasted, mutated, and scattered over these tubes like a disturbing game of telephone on Moore’s law. This new update to reset.css is great and well needed. I hope it further aides in teaching a new generation of CSS sages and proliferates farther than its predecessor.

    • #33
    • Pingback
    • Tue 4 Jan 2011
    • 1359
    Received from Easy HTML5 Template

    […] Updated the CSS reset to Meyer’s latest which I had no idea was updated just yesterday; made some small indenting fixes, plus corrected the […]

    • #34
    • Comment
    • Tue 4 Jan 2011
    • 1510
    Michael Neth wrote in to say...

    Eric, have you ever given thought to defining a baseline styling to go along with your reset, similar to what Tripoli was doing? For the people that do just copy it without thinking (which sucks, sure, but is going to continue to happen), I wonder if it would help make the web a better place to give them some simple consistent styling. I know that’s not what the reset is for, but just a thought.

    • #35
    • Pingback
    • Tue 4 Jan 2011
    • 1530
    Received from Eric Meyer Updates CSS Reset | ChurchCreate

    […] Design, News, Web Tools0Eric Meyer Updates CSS Reset Posted by John Saddington on Jan 4, 2011Eric Meyer, the creator of really the first “global” CSS Reset has updated his code of the reset […]

    • #36
    • Comment
    • Tue 4 Jan 2011
    • 1626
    Philip Renich wrote in to say...

    In regards to :focus, I’m curious what you all think about the use of it on a global level. I don’t like the added ‘default’ (standard dotted border that is usually used on anchor tags) around my form elements. I haven’t ever seen the need to visually style this for input elements (at least of the text(+search etc) types and textarea). The UA inserts the cursor which is visual.

    Would it perhaps be more accurate to use a:focus instead?

    Discuss :)

    • #37
    • Pingback
    • Tue 4 Jan 2011
    • 1626
    Received from HTML5 Checklist – dale sande - ui engineer

    […] I am a fan of Eric Meyer’s CSS Reset […]

    • #38
    • Comment
    • Tue 4 Jan 2011
    • 1754
    Peter Wilson wrote in to say...

    @Evandro Oliveira – I’m aware of this, in a production environment :link, :visited, :hover & :active would have a transparent b/ground. I was just trying to make the example clearer.

    • #39
    • Pingback
    • Tue 4 Jan 2011
    • 2016
    Received from links for 2011-01-04 | James A. Arconati

    […] Eric's Archived Thoughts: Reset Revisited It was close to four years ago now that I first floated (ha!), publicly refined, and then published at its own home what’s become known as the “Eric Meyer Reset”. At the time, I expected it would be of interest to a small portion of the standards community, provoke some thought among fellow craftspeople, and get used occasionally when it seemed handy. Instead, it’s ended up almost everywhere. […]

    • #40
    • Comment
    • Tue 4 Jan 2011
    • 2035
    Jacob Gube wrote in to say...

    I partially agree with Carsten’s comment regarding sup and sub. In the same way del is set to have text-decoration: line-through, which is a common style of this element, sup and sub could have vertical-align:super and vertical-align:sub, and perhaps a font-size property with a relative-unit value (maybe 10-20% of the parent element) or perhaps just a reminder to set the font-size, like with the outline property on the :focus pseudo-class.

    I wouldn’t take them out of the big selector though so that I wouldn’t have to restate that margin, padding, etc. properties; I would treat them similarly to how del is declared.

    • #41
    • Comment
    • Tue 4 Jan 2011
    • 2244
    Michael Tuck wrote in to say...

    I blush, I simper at being cited. ;) Thanks, Eric. Hope you’re enjoying your museum passes! While you’re indulging the kiddies, I’m going to take some time this weekend and dig into your new reset.

    • #42
    • Comment
    • Tue 4 Jan 2011
    • 2318
    Cogito wrote in to say...

    @Philip Renich I agree. I’m not entirely sure how big the difference is between “a:focus” and “:focus” (if at all), but I figure it’s the kinda thing people really only need on anchors, for accessibility ‘n such. Why use it on all focusable elements? :) Or am I being trite?

    • #43
    • Pingback
    • Wed 5 Jan 2011
    • 0651
    Received from Eric Meyer CSS rest 2011 & refactoring

    […] Meyer CSS rest 2011 & refactoring Eric Meyer has updated his CSS reset for 2011, which got me to thinking how much I go back and look at old code and refactor it. I do this all […]

    • #44
    • Comment
    • Wed 5 Jan 2011
    • 0940
    Eric Meyer wrote in to say...

    Sorry I was absent yesterday—life intervened.

    Regarding subscripts and superscripts, I reset their vertical alignment for the same reason I reset margins on paragraphs and lists: to remove as many browser defaults as is practical and get the designer to think closely about how to handle all of the presentation in a given design.

    Of course, anyone who dislikes that particular bit could modify their own reset along the lines mentioned above. Or they could create some other personalization. This is, as ever, a starting point for individual crafting, not an untouchable ideal.

    Ryan: I think most of your questions are answered by the 2007 posts Reset Reasoning and Formal Weirdness.

    Michael: not really. Everyone’s baseline is different. Though it could be interesting to create a baseline, replace the specific values with “?????”, and push that into the world. Perhaps when I finish this revision I’ll give that some thought.

    Jacob: I left del the way it is partly for historical reasons, but your prodding makes me think that maybe I should take those lines out entirely and replace them in a baseline like Michael suggests.

    • #45
    • Comment
    • Wed 5 Jan 2011
    • 1025
    Bobby Jack wrote in to say...

    To all those saying “doesn’t {style} defeat the purpose of {element}”: no, it doesn’t! HTML describes the semantics of your content, not the styling, so styling cannot defeat the purpose of any element. Even if every single element in your page has all its styles removed, it still makes sense to use elements to describe your content. Having said that, I do agree that there’s little (or no) benefit in resetting things like the vertical alignment of the superscript element.

    @Evandro: setting the background of a link to transparent can still be a problem – what if that link is then placed over a background with the same color as that link’s foreground?

    @Philip: styling the current form element is often done to draw attention to it. It’s potentially useful if the eye is drawn elsewhere, then needs to return. Of course, it’s should almost certainly be styled differently from a focussed link!

    • #46
    • Comment
    • Wed 5 Jan 2011
    • 1045
    Rich Clark wrote in to say...

    Hey Eric

    Thanks for the reference to the HTML5 Doctor reset :)

    I’m wondered what you felt we went too far with? (ins and mark having specific styles is a given but what else?).

    Also I’m guessing you’ve left the absent HTML5 elements (acronym, strike, etc) in as this reset isn’t supposed to be specific to a single version of HTML (or XHTML)?

    To clarify, I wrote that reset for my needs (as you did with your original I guess), hence it not being a pure reset. Having re-read the article that’s perhaps not clear – I should look at that I guess. However, people are free to use, customise and abuse as they wish.

    • #47
    • Pingback
    • Wed 5 Jan 2011
    • 1110
    Received from WebAIM: Blog - Progress on outline:0

    […] focus indicator. One of the most popular of these reset files is Eric Meyer’s reset.css. In a recent update to reset.css, Eric has now commented out the line that removes focus indicators, thus requiring author […]

    • #48
    • Comment
    • Wed 5 Jan 2011
    • 1113
    Paul D. Waite wrote in to say...

    > “Removed font from the selector of the first rule. It’s been long enough now, I think. We can let that one go.”

    In a sort of similar vein, I’ve removed b, i and u from that selector a couple of times, for content-managed sites where some editor in the future might use those tags and wonder why they don’t work.

    • #49
    • Pingback
    • Wed 5 Jan 2011
    • 1116
    Received from Eric Meyer’s Revised CSS Reset « Jaime's Expressions

    […] Out of habit, I tend to start my projects using Eric Meyer’s reset, but with HTML5 and CSS3 coming into play, there is a need to revisit the code. Eric Meyer’s has done this so for all CSS Reset users, take a look at the updated reset stylesheet. […]

    • #50
    • Comment
    • Thu 6 Jan 2011
    • 0838
    Evandro Oliveira wrote in to say...

    @Bryan, body isn’t inline element.

    @Bobby, background for anchors (and many other elements), is the default set to transparent on all the major browsers (Firefox, Chrome, IE, Safari, Opera).

    Validating – via W3C – your CSS, the validator warns you about this issue (same text for foreground and background colors). But it can also be a trick to hide text inside elements, since text-indent:-999px isn’t SEO friendly.

    • #51
    • Pingback
    • Fri 7 Jan 2011
    • 1519
    • #52
    • Comment
    • Sat 8 Jan 2011
    • 0623
    Tim Petch wrote in to say...

    Glad i didn’t miss this! many thanks. I have been reading lately into the negatives of reseting due to browser defaults but i still personally reset, having said that the previous comment referring to a simple consistent styling sheet might overlap with this nicely!

    • #53
    • Pingback
    • Sat 8 Jan 2011
    • 2302
    Received from Popular ‘CSS Reset’ Stylesheet Gets an HTML5 Makeover | Al Terry Gough

    […] can grab the latest version of Meyer’s reset stylesheet from his website (note that Meyer’s main reset page still hosts V1, for the updated version […]

    • #54
    • Comment
    • Sun 9 Jan 2011
    • 1119
    Alan Gresley wrote in to say...

    I see nothing different.

    Talking about resets being out there, and everywhere. My table of CSS2.1 User Agent Style Sheet Defaults is a popular page on my site but all the links are from other pages about how to do resets. This is not the reason that I provided such a resource. I will assure whoever that the reasons for using resets are gradually disappearing.

    • #55
    • Pingback
    • Sun 9 Jan 2011
    • 1215
    Received from The CSS reset has been reset « Gabriel de Kadt

    […] grandaddy of all CSS resets hits version 2.o beta: Eric Meyer’s Reset Revisited. See also the subsequent thoughts on how to handle […]

    • #56
    • Pingback
    • Sun 9 Jan 2011
    • 1814
    • #57
    • Comment
    • Thu 13 Jan 2011
    • 1848
    dgl wrote in to say...

    Thanks for your work! Could you please host your CSS reset as GitHub Gist or maybe in a git repo so it would be easier to track changes?

    • #58
    • Pingback
    • Fri 14 Jan 2011
    • 0639
    • #59
    • Pingback
    • Fri 11 Feb 2011
    • 2139
    Received from Links 2-11-11: Mubarak resigns, iAds in peril, PayPal micropayments | Aram Zucker-Scharff

    […] Starting to play with HTML5? It may be time to amp up your style reset code. Eric Meyer has the new CSS for you. […]

    • #60
    • Pingback
    • Sat 14 May 2011
    • 0925
    Received from Eric Meyer Updates CSS Reset | Church Mag

    […] Eric Meyer, the creator of really the first “global” CSS Reset has updated his code of the reset (found here) with some of the following changes: […]

    • #61
    • Comment
    • Mon 23 May 2011
    • 2007
    Shauna wrote in to say...

    @Paul D Waite – <b> and <i> were never deprecated, and are, in fact, actually given a defined purpose in HTML5. So editors that use them won’t be any the wiser, even if they don’t use it for the right reasons. Just something to keep in mind.

    • #62
    • Comment
    • Mon 13 Jun 2011
    • 1008
    Paul D. Waite wrote in to say...

    “I will assure whoever that the reasons for using resets are gradually disappearing.”

    That depends on the reasons people have for using them though, doesn’t it?

    Personally, I use a reset just because it forces me to deliberately think about every style that I’m applying to the site. I find doing that makes my code, and my design, better.

    • #63
    • Pingback
    • Fri 24 Jun 2011
    • 1030
    Received from HTML5 “ecard” | Pedro Albea

    […] because everybody seems to be using jQuery these days, modernizr for IE, and a full blown CSS Reset.  You basically can just chop off what you don’t need and get to […]

    • #64
    • Comment
    • Wed 29 Jun 2011
    • 0917
    Dan wrote in to say...

    Here’s one more for you to ponder about:

    select, input, textarea {
    -webkit-box-sizing: border-box;
    -moz-box-sizing: border-box;
    box-sizing: border-box;
    }

    Select elements use the content-box in pretty much every browser. That’s why they never actually have the same size as the other elements, even if all have the same dimensions set. I also found a bug report from Firefox for this problem: https://bugzilla.mozilla.org/show_bug.cgi?id=562153

    The code works from IE8 and up and all other major browsers, according to PPK: http://www.quirksmode.org/css/contents.html

    • #65
    • Comment
    • Mon 25 Jul 2011
    • 1922
    Adam Samec wrote in to say...

    Hello Eric, the reset is really a useful thing, I especially like the font:inherit trick.
    However, I want to point out a bug in IE that is somewhat relevant to the reset. The problem is that font-size:100% set on each element kicks off a chain reaction of how the size of <sup>‘s or <sub>‘s descendants is determined. This is solved by IE8’s font:inherit support, but still affects the older versions. I have described the bug more here. But maybe now is the time when IE7 should be slowly burried next to IE6.

    To my next point, is there something more behind the reason why margin, padding and borders are also being reset on inline elements (Scott and Grant Husbands have already touched the topic), or it just hold the line with the others insuring that everything is in a plain baseline?

    • #66
    • Comment
    • Tue 26 Jul 2011
    • 1011
    escoles wrote in to say...

    You may be able to let font go, but we see it enough (mostly in pasted Word text) that we can’t. Easy enough to add, though.

    comments on <i> and <b> are well-taken, also: The first thing I have to do with a reset is to get rid of the weight: normal reset on those, since (again) we see them all the time in code pasted from Word.

    • #67
    • Comment
    • Fri 5 Aug 2011
    • 0358
    Peter wrote in to say...

    Wouldn’t it be nice if browsers granted a performance benefit to pages with a certain META tag that prevented any browser style from being applied in the first place? Such a “no set” tag would leave the slate clean in a way equivalent to a nice, vigorous reset.

    I half expect to be told this kind of setup is in progress somewhere…

    • #68
    • Comment
    • Mon 15 Aug 2011
    • 1959
    reevolver wrote in to say...

    Rewheeling is the painful symptom. Abstraction the solution, but not in isolation. CSS * Browser render engines * Devices- seems an infintly intractable problem. Standards by adoption isn’t working. What a mess, what to do?

    Display should not be the defining advantage of browsers. CSS for all its easy entry point is awful as a language paradim. All inheritance no compositon and massive repetition, rigidity and fragility.

    The way forward? 10 more years of pain. Browser inconsistencies seem to be lessening, but the only force driving this is developer pain. sorry but thats not a good enough reason. we need to design, develop, broker and drive a better solution.

    • #69
    • Pingback
    • Tue 20 Sep 2011
    • 1135
    Received from HTML5 Boilerplate and why you should give it a try | Stefano Restaino - Front End Web Developer Portfolio & Blog

    […] makes it more of a powerful tool in comparison to a reset stylesheet, such as the popular ‘Reset Revisited‘ created by Eric Meyer and HTML5 Doctor Reset Stylesheet. Whilst a reset stylesheet will […]

    • #70
    • Pingback
    • Tue 8 Nov 2011
    • 0856
    Received from Cross-Browser CSS Development Workflow | Impressive Webs

    […] Eric Meyer’s most recent CSS reset. If you’re hesitant to use something that the author himself has labelled “a work in […]

    • #71
    • Pingback
    • Fri 11 Nov 2011
    • 1246
    Received from How To Use a CSS Reset | Flarnie Marchán

    […] you’re in a hurry, just grab the latest version of Eric Meyer’s CSS Reset, it’s considered a […]

    • #72
    • Pingback
    • Tue 17 Apr 2012
    • 1032
    • #73
    • Pingback
    • Tue 3 Jul 2012
    • 1534
    Received from Ingredients of a website - Redfish Bluefish Media

    […] is our home-baked WordPress framework, which includes the 960.gs system, a modified version of the Meyer CSS Reset, and much more. Importantly, it also includes a custom options panel which we use on every site to […]

    • #74
    • Comment
    • Wed 4 Jul 2012
    • 0959
    Stoffb wrote in to say...

    Hey, thanks for the upgrade.
    Is there a minified version available too by any chance?
    Many thanks

    • #75
    • Pingback
    • Tue 17 Jul 2012
    • 0907
    Received from Links from the “Creating an Accessible Layout” Webinar | JTF Associates, Inc.

    […] Meyer’s original Reset CSS and Reset CSS […]

    • #76
    • Pingback
    • Sat 9 Feb 2013
    • 1119
    Received from CSS resets: what are they and why do i need one?

    […] Eric Meyer’s Most Recent Reset and his Original Reset […]

    • #77
    • Pingback
    • Thu 30 May 2013
    • 1551
    Received from A Simple, Responsive, Mobile First Navigation | Joliet Junior College-Web Design Certificate

    […] I’ve always found Eric Meyer’s reset to be a solid basis to work from, especially as he’s tweaked it recently. We’ll add his reset rules to a stylesheet to kick our css […]

    • #78
    • Comment
    • Thu 26 Sep 2013
    • 0443
    Valentin wrote in to say...

    Small correction if allow me:
    ‘html’ does not need “margin:0″ or “padding:0″ (only “border:0″ for IE if you wish)
    elements like ‘body’, ‘p’, ‘pre’.. doesn’t need padding also…
    with ‘margin:0′ is enough

    • #79
    • Comment
    • Sun 14 Dec 2014
    • 2333
    Dim wrote in to say...

    Thanks Eric! Is this reset still applicable for today? I’m starting to get back into it so I need to brush my skills up.

Leave a Comment

Line and paragraph breaks automatic, e-mail address required but never displayed, HTML allowed: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>



Remember to encode character entities if you're posting markup examples! Management reserves the right to edit or remove any comment—especially those that are abusive, irrelevant to the topic at hand, or made by anonymous posters—although honestly, most edits are a matter of fixing mangled markup. Thus the note about encoding your entities. If you're satisfied with what you've written, then go ahead...


January 2011
SMTWTFS
December February
 1
2345678
9101112131415
16171819202122
23242526272829
3031  

Sidestep

Feeds

Extras