Stop Using Resets: Visual Examples of the Practical Nonsense of Resets and Normalizers

Published on July 13, 2017 (↻ June 5, 2021), filed under (RSS feed for all categories).

Reset style sheets, I’ve long had it with them: Resets, as well as normalizers, are quite practically useless. I’m not sure why they keep being such a topic for me; I feel like a ghost in some haunted house not finding rest. Perhaps it’s because I’ve been complicit, or because I haven’t yet built the perfect case after all.

Maybe this time. In prior criticism of the quality of WordPress themes we’ve noticed a bit more tangibly how unnecessary resets really are. The idea of simply “turning off” resets to see whether they were actually needed has apparently not come to many using them; now it seems the same can be said of the critic đŸ˜‰ Equipped with the Reset Style Sheet Highlighter extension I took note over the last few weeks whenever I saw a site using a reset or normalizer. And that work, shown here (after diff’ing plenty of screenshots with Resemble.js), should allow us to see why resets aren’t just theoretically but quite very practically silly: What they do we often do anyway, or can we easily achieve with one or two declarations instead of an entire extra style sheet.

Visual diff of agoracommsy.uni-hamburg.de.

Figure: agoracommsy.uni-hamburg.de with and without a reset, and instead of using a reset one or two tweaks may have sufficed.

Visual diff of asus.com.

Figure: asus.com with and without a reset, and again it seems like the reset wasn’t needed.

Visual diff of brucesterling.tumblr.com.

Figure: brucesterling.tumblr.com with and without a reset, and ditto.

Visual diff of christophmagnussen.com.

Figure: christophmagnussen.com with and without a reset, and at the moment it looks like one CSS modification could also do the trick.

Visual diff of geopoliticalfutures.com.

Figure: geopoliticalfutures.com with and without a reset, and we can’t spot any difference. Poster child.

Visual diff of gimp.org.

Figure: gimp.org with and without a reset, and this looks much worse than things are (compare with the individual screenshots).

Visual diff of iplocation.net.

Figure: iplocation.net with and without a reset, and here, too, the diff looks more problematic than what we actually have to address after deleting normalize.css.

Visual diff of loopia.se.

Figure: loopia.se with and without a reset, and similar to gimp.org and iplocation.net is the diff a bit deceptive—the differences are easy to spot and easy to fix, to not require a reset, not on this page.

Visual diff of majestic.com.

Figure: majestic.com with and without a reset, and who spots the difference.

Visual diff of marketever.com.

Figure: marketever.com with and without a reset, and we can be confident again that a reset wasn’t needed, either.

Any sample I took led to results like these, and the glitches, no matter that I like to exaggerate here as I sometimes do (and I do so covertly as well for of course, the sites run deeper, and so yes, theoretically hell could break loose on sub pages), can so far all be fixed pretty swiftly. That, lest I forget, includes possible cross-browser differences. None of the sites appear to warrant an additional style sheet that sets either something to be overwritten or not to be used.

Now, it’s not inconceivable that someone really, really, really needs a reset style sheet. Like a research coder who wants to show to the world that one can enforce user agent style sheet styling, or that it’s possible to eradicate all browser support differences by leveling the playing field through a universal style sheet. Alas, that doesn’t mean anyone else needs it. Unfortunately for our entire field, we ran after this sort of mirage for more than a decade. It’s time to stop. Stop using reset style sheets and normalizers. We’ll all be fine. And better off.

Have I provided too few examples? Have I glossed over the topic of cross-browser considerations? Or should I have used stronger wording? Let me know in the comments.

Was this useful or interesting? Share (toot) this post, or support my work by buying one of my books (they’re affordable, and many receive updates). Thanks!

About Me

Jens Oliver Meiert, on September 30, 2021.

I’m Jens (long: Jens Oliver Meiert), and I’m a frontend engineering leader and tech author/publisher. I’ve worked as a technical lead for companies like Google and as an engineering manager for companies like Miro, I’m somewhat close to W3C and WHATWG, and I write and review books for O’Reilly and Frontend Dogma.

I love trying things, not only in web development (and engineering management), but also in other areas like philosophy. Here on meiert.com I share some of my views and experiences.

If you’d like to do me a favor, interpret charitably (I speak three languages, and they do collide), yet be critical and give feedback, so that I can make improvements. Thank you!

Comments (Closed)

  1. On July 14, 2017, 1:12 CEST, Hanna said:

    Just the right wording.

  2. On July 14, 2017, 14:08 CEST, n.b said:

    You missed the point, that the customer must be satisfied
 and if it looks different in IE than in Chrome you did not do your job right


    Plus if everything looks the same in all browsers then the communication with the client is better as you are not guessing what browser is he using and can reproduce the issue more easier.

  3. On July 14, 2017, 15:32 CEST, Jay said:

    Reset style sheets, though, save you the time of doing these comparisons in multiple browsers to determine what needs styling and what doesn’t. It might be the case that Chrome’s default h1 margin, for instance, puts things where you want them, but Firefox’s doesn’t. normalize.css is 2Kb gzipped; Eric Meyer’s is 625 bytes. Is that really that costly?

  4. On July 14, 2017, 19:24 CEST, Dwight House said:

    My CSS reset on my current project represents an extra page weight of 238 characters (187 bytes gzipped). As an experiment, I removed the reset, and checked the comparison. The result: “The second image is 42.88% different compared to the first. And they have different dimensions.”

    If your logic is correct, I should be able to change a couple styles here and there and get it to be identical, and doing so should cost less characters than just including the reset. Doing this is certainly not easier on the developer, so this is a loss to maintainability. Your argument will only be valid in my case if bytes are saved.

    
and I didn’t have to get very far. Simply adding “border:0;” to all my button classes resulted in an extra 252 characters in my stylesheet, larger than the entire reset. After doing this, the output difference was 42.85% different, a 0.03% improvement, which is reasonable given that I only changed the border size on buttons.

    Your argument is simply incorrect for sufficiently general resets. Here is my reset:

    html{box-sizing:border-box;height:100%}
    *,:after,:before{margin:0;padding:0;border:0;outline:0;box-sizing:inherit}
    ::-moz-focus-inner{border:0}
    body{position:relative}
    a{text-decoration:none;color:inherit}
    a:focus{outline:0}
    ul{list-style:none}
  5. On July 15, 2017, 8:35 CEST, Evan Payne said:

    All of your screenshots were made with Firefox. While it’s true that for a particular browser a reset doesn’t do much, we usually have requirements to make the designs look the same on Chrome, Safari, Edge, IE10+, and maybe even Opera.

    The idea of normalisation is what we’re really talking about here. I’ve turned to using tinyreset lately, so there’s a smaller footprint, but I don’t see that I wouldn’t waste hours troubleshooting little mistakes in each browser without this.

  6. On July 16, 2017, 19:30 CEST, Chris said:

    You’re neglecting the benefit during development of knowing that anything you see an element doing is because you’ve explicitly set it.

  7. On July 16, 2017, 19:38 CEST, Jens Oliver Meiert said:

    @Dwight, the primary argument against resets is first and foremost that they either contain unapplied styles or that what they contain gets overwritten, both of which means that they’re superfluous. Particularly the “no differences” diffs illustrate that well.

    There are other cases, and gimp.org may be one from the sample, where this isn’t trivial. Indeed, one would need to dissect these cases more carefully.

    As I believe or hope prior articles (see what I referenced in the beginning of this post) explain the general problematique, there’s just one more thing to add: Keeping our CSS DRY should prevent us from some of the hassle that you’re describing, because the little duplication we deal with then cannot lead to much maintenance work, nor issues with file sizes.

    All written down a bit swiftly, happy to share more thoughts, thank you and all the others who have commented one way or other.

  8. On July 18, 2017, 18:32 CEST, Gerhard Großmann said:

    I often start with an accompanying reset file but look through it. In this process I delete what I don’t need, transfer into my own style sheet what I forgot, and incorporate what could be an useful addition.

    In the end no reset styles are left. So I wouldn’t say reset style sheets are nonsense – but only if you supersede them.

  9. On July 19, 2017, 16:48 CEST, Bob said:

    Seems click baity to me. Also, normalizer and reset are two different things.

  10. On July 19, 2017, 16:54 CEST, Bob said:

    Additionally, the reset debate ended years ago. Not sure why you would not just be using normalization, or, do nothing at all like the trends have been heading. This article feels like a blast from past.

  11. On July 19, 2017, 18:19 CEST, Josh Habdas said:

    It’s never too late to challenge the status quo. And no reset nor normalizer today will ever hold into the future. If the browser get the spec wrong there’s no reason for everyone else to paper over it - that only hurts the spec itself. Bravo and thanks for the call JavaScript tool you linked.

  12. On July 19, 2017, 18:56 CEST, Christian said:

    I came up with a solution to this a few years back that I would say was darn near perfect and created no unnecessary code and was extremely sensible, but nobody seemed to care. Actually, it was completely perfect.

    Another thing to keep in mind is that I don’t believe Eric Meyer ever said to use resets blindly but to delete any suggested ones that weren’t needed in a particular project and to be open to tweaking values of the ones that were left in the project.

  13. On July 20, 2017, 9:30 CEST, Mattia said:

    I agree with you, but you miss the focus of normalize. Normalize is useful to “normalize” default styles across the browsers. So in your examples you should show differences with/without across browsers.

  14. On July 24, 2017, 9:05 CEST, Dave said:

    Doing these tests on a modern browser wasted your time and now mine

  15. On July 25, 2017, 11:09 CEST, Jens Oliver Meiert said:

    @Dave, what browsers are most relevant to you? I deem the case long closed but I like the idea of preparing additional diffs for older user agents.

  16. On July 26, 2017, 13:51 CEST, Brian said:

    I’m going to keep using resets. It takes seconds for me to add the line that brings in the reset rules, where it would take far too long to write rules specific to each user agent. I’m winning as soon as my client queries the size or position of an element in a view and I don’t need to ask “which browser are you using?”

  17. On July 28, 2017, 9:33 CEST, Ailin Hernandez said:

    Good demonstration, really enjoyed the findings. Sadly, most costumers aren’t happy to see their website displayed different in diverse environments. I believe we should start evolving the mindset of clients that want pixel perfection.