Reset Revisited
Published 13 years, 10 months pastIt 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 forbackground-color
(whichbackground
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 understandinherit
, but support is now widespread enough that I feel this can go in. I leftfont-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
- Korean by Kyung il Park
Comments (83)
Thanks a lot Eric. One question which versions of IE do you consider “older versions”? 6 and lower?
Definitely IE6 and earlier, Leonardo, and here I’m also referring to IE7 with regards to
inherit
, which IE7 didn’t really support.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…
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.
Thank’s Eric. Compressed and now residing in my code clips!
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.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
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.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. :)
As Paul said, we reset the anchors separately in HTML5 Boilerplate and reset outline on :hover/:active (keeping the default outlines only on :focus).
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 forli
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.
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!
I don’t understand why you assign
font-size: 100%;
vertical-align: baseline;
to
sub
andsup
.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?
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.
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 :)
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?
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
, andsup
it should be removed from first block due to the nature of the element. Having thevertical-align
override the default makes it pointless, and harder to redefine later in the stylesheet.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.
Peter (@ #11 comment) Anchors and any other inline element should have ‘transparent’ background, not white.
Pingback ::
Around the Web: Nike’s World, URL Design, & facto.Me’s First 50 hrs | Think Vitamin
[…] "must read." Reset Revisted by Eric […]
Pingback ::
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 […]
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.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).
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).
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.
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.
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.
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.
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
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?
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.
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.
Pingback ::
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 […]
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.
Pingback ::
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 […]
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 :)
Pingback ::
HTML5 Checklist – dale sande - ui engineer
[…] I am a fan of Eric Meyer’s CSS Reset […]
@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.
Pingback ::
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. […]
I partially agree with Carsten’s comment regarding sup and sub. In the same way
del
is set to havetext-decoration: line-through
, which is a common style of this element,sup
andsub
could havevertical-align:super
andvertical-align:sub
, and perhaps afont-size
property with a relative-unit value (maybe 10-20% of the parent element) or perhaps just a reminder to set thefont-size
, like with theoutline
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.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.
@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?
Pingback ::
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 […]
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.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!
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.
Pingback ::
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 […]
> “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.
Pingback ::
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. […]
@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.
Pingback ::
» [Friday Links] The First Week Back Edition - Wayne State Web Communications Blog
[…] Reset Revisited […]
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!
Pingback ::
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 […]
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.
Pingback ::
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 […]
Pingback ::
My Tweekly Updates for 2011-01-09 | visaap.nl
[…] Reset Revisited | @meyerweb – http://meyerweb.com/eric/thoughts/2011/01/03/reset-revisited/ […]
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?
Pingback ::
The history of CSS resets — ldexterldesign ❤ Bristol-based freelance Designer & Developer
[…] http://meyerweb.com/eric/thoughts/2011/01/03/reset-revisited/ […]
Pingback ::
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. […]
Pingback ::
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: […]
@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.
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.
Pingback ::
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 […]
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
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’sfont: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?
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.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…
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.
Pingback ::
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 […]
Pingback ::
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 […]
Pingback ::
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 […]
Pingback ::
Designing Applications With Web Standards – or, HTML is the API – Jeffrey Zeldman Presents The Daily Report
[…] CSS Reset, Eric Meyer, v 2.0b1, January 2011 […]
Pingback ::
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 […]
Hey, thanks for the upgrade.
Is there a minified version available too by any chance?
Many thanks
Pingback ::
Links from the “Creating an Accessible Layout” Webinar | JTF Associates, Inc.
[…] Meyer’s original Reset CSS and Reset CSS […]
Pingback ::
CSS resets: what are they and why do i need one?
[…] Eric Meyer’s Most Recent Reset and his Original Reset […]
Pingback ::
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 […]
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
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.
You should add the SVG element. It has a margin at the bottom by default.
Pingback ::
Things Every Designer Needs to Know about Accessibility | Explore Everyday
[…] a keyboard. Fortunately, since the initial CSS resets were released, many popular ones including Eric Meyer’s have been updated to remove un-styling of the :focus […]
Pingback ::
300+ CSS Resources to Speed Up your Development — Page Config
[…] Eric Meyer Reset […]
Pingback ::
10 critical reasons to speed up your website in 2020 – Zozal Internet, LLC
[…] first thing we did when setting up our CSS file was to use a reset that the rest of the file would be built […]