Stop Using Resets: Visual Examples of the Practical Nonsense of Resets and Normalizers
Published on July 13, 2017 (⻠June 5, 2021), filed under Development (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.
Figure: agoracommsy.uni-hamburg.de with and without a reset, and instead of using a reset one or two tweaks may have sufficed.
Figure: brucesterling.tumblr.com with and without a reset, and ditto.
Figure: christophmagnussen.com with and without a reset, and at the moment it looks like one CSS modification could also do the trick.
Figure: geopoliticalfutures.com with and without a reset, and we canât spot any difference. Poster child.
Figure: gimp.org with and without a reset, and this looks much worse than things are (compare with the individual screenshots).
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.
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.
Figure: majestic.com with and without a reset, and who spots the difference.
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.
About Me
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)
-
On July 14, 2017, 1:12 CEST, Hanna said:
Just the right wording.
-
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.
-
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?
-
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}
-
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.
-
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.
-
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.
-
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.
-
On July 19, 2017, 16:48 CEST, Bob said:
Seems click baity to me. Also, normalizer and reset are two different things.
-
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.
-
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.
-
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.
-
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.
-
On July 24, 2017, 9:05 CEST, Dave said:
Doing these tests on a modern browser wasted your time and now mine
-
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.
-
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?â
-
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.
Read More
Maybe of interest to you, too:
- Next: Boyscout Code
- Previous: Highlights From Martinâs âThe Behavior of Crowdsâ
- More under Development
- More from 2017
- Most popular posts
Looking for a way to comment? Comments have been disabled, unfortunately.
Get a good look at web development? Try WebGlossary.infoâand The Web Development Glossary 3K (2023). With explanations and definitions for thousands of terms of web development, web design, and related fields, building on Wikipedia as well as MDN Web Docs. Available at Apple Books, Kobo, Google Play Books, and Leanpub.