There’s a reason neither has seen more recent activity: they were mostly about making old browsers behave themselves, and they’re done. The stylesheets did have a little more to them, but it wasn’t what people actually cared about… and in some cases they were better off without them. I know I disagree with quite a few of their opinionated styles.
Those old browsers are now long obsolete—half of them can’t even talk TLS 1.2, which basically excludes them from the modern web—so almost all of these stylesheets is obsolete, and you don’t need them.
For the few pieces that might still have value, you would now prefer to use @layer or :where() for this kind of stylesheet, to make them behave more like user agent styles and avoid specificity conflicts.
To add to this, HTML 5/LS have a section on rendering HTML elements [1]. That section provides default CSS rules that a conforming web browser must use. Therefore, modern browsers effectively have built-in normalize.css rules, providing a consistent web page default.
There may be some rules you want to change in a set of baseline rules such as margin/padding, image sizing, and fonts. But those would be things you would add on top of normalize.css anyway.
In the nearly 25 years of running a web dev company, we never used such resets because it always felt like browsers had their built in settings, then one would have a reset to shift everything around one way, then we'd have settings to throw things another way and that's how it felt--like we were slamming things back and forth far too much.
Instead, we'd just set elements to what we wanted them to be which is what we'd have to do in most cases anyway, making any reset unnecessary.
They more or less had the same goals, different ways of achieving them.
- CSS reset - completely reset all browser styles to be blank essentially, across different browsers, so then you'll build your styling on common ground
- CSS normalize - same idea of resetting to a baseline, but keeping some of the default styling but still make it consistent across browsers, so not stripping away everything
Presumably, a reset is resetting to a browser's defaults, whereas a normaliser is about establishing a cross-browser default. I haven't done much web-dev in recent years, but I vividly remember the same page looking different in different browsers, particularly prior to HTML5.
No, a browser's defaults are, well, its defaults. One doesn't reset to them.
I think the line between a normalizer and reset stylesheet is _very_ fine, if there even is a line. A normalizer is probably _slightly_ more opinionated than a reset stylesheet. In the end, the difference isn't really important. If you need a reset stylesheet, normalizer will probably do just as well.
I moved away from using Tailwind CSS, but still use their "preflight.css" [1]. It doesn't really care about backwards compatibility (IE stuff), but does a great job at unstyling everything so you have a clean cross-browser base to work with (button will look like text until you add your styling).
I took a look thinking that this might actually be useful and somehow came away with an even lower opinion of Tailwind. It’s all like this:
/*
1. Add the correct height in Firefox.
2. Correct the inheritance of border color in Firefox. (https://bugzilla.mozilla.org/show_bug.cgi?id=190655)
3. Reset the default border style to a 1px solid border.
*/
hr {
height: 0; /* 1 */
color: inherit; /* 2 */
border-top-width: 1px; /* 3 */
}
Why can’t they do anything reasonably? It would be easy to put code comments against the actual code it is commenting, but instead they do this weird comment index up front.
Could you write a few words why you moved away from TailwindCSS?
I am an amateur dev (I write open-source useful for me and possibly others) and I am prone to the "front-end diarrhea syndrome", where when I see something cooler, I jump on it and regret afterwards the time spent.
I am on TailwindCSS right now and I am afraid to learn the drawbacks, but one must be courageous in life.
Thank you, this is a nice post. On the other hand, the author is happy to have HTML and CSS generated with JS, which is weird as well (I know - React).
It has some good points (and vanilla-extract IS awesome), but it's also a bit unfair, eg ignoring tailwind affordances like `apply`.
That said, for learning the "right" way to think about and use CSS, https://every-layout.dev is hands-down the best resource I've encountered in my 20+ years working with websites.
Now, to be fair, they wrote the article in 2025, and Tailwind linting was only released five years prior (in 2020) ... five years is hardly long enough to learn relevant tech for your industry /s
The rest of the article seemed similarly ill-informed, with the author fixating on meaningless byte-size differences in contrived examples. However, he ignores the fact that Tailwind is used on some of the most performant sites on the Internet. He also ignores the fact that (for 99% of sites at least) sacrificing a k or two of bandwidth is well worth it for a major increase in developability.
With Tailwind you completely get rid of stylesheets: that alone is huge! There's a reason why so many devs use Tailwind: they don't worry about minimal file size differences, but they do care about massive savings in development time and complexity reduction.
Kind of a bummer it only targets the latest version of browsers. I get trying to remove cruft by not trying to support older versions, but if you only support the latest you're targetting a smaller % of browsers.
> Nicolas Gallagher and I started writing normalize.css together. I named and created the normalize.css repository with the help of Paul Irish and Ben Alman. I transferred the repository to Nicolas, who turned it into a “household” CSS library.
> Later, I resumed authorship of normalize.css with Luciano Battagliero. Together, we tagged, deprecated, and removed “opinionated” styles — styles developers often prefer but which do not fix bugs or “normalize” browser differences.
> Later, Nicolas resumed authorship and the issue of whether to include or omit the opinionated styles forced us to split.
At some point I stopped caring about backwards compatibility, but I can’t put my finger on it.
Perhaps connectivity became so good that now as long as it works on evergreen, it’s good to go. We used to put a lot of effort into this stuff, but it feels like it’s been years since we even thought about it.
Obviously we can't break backwards compatibility, but why doesn't css have opt-in "use version" strings that could tell the browser: I want this set of defaults. Something like "use-defaults: system-ui;" or "use-defaults: none".
Looks unmaintained, last release 2 years ago. The website points at v11 when the most recent release is v12. Has nothing changed in browsers to necessitate code changes?
CSS is a monster, and it just keeps growing. If one wants to do something truly visually crazy / innovative / impressive, just use canvas. Didn't Google Docs abandon CSS and go straight with canvas? The feature creep in CSS is distasteful. The counter argument is if we keep adding features that will keep the LLMs at bay as they are not good at extrapolation and / or stuff they have not seen before. rant over.
This link is for the less-well-known normalize.css, https://github.com/csstools/normalize.css. It was last touched five years ago.
The better-known normalize.css is https://github.com/necolas/normalize.css. It was last touched seven years ago.
There’s a reason neither has seen more recent activity: they were mostly about making old browsers behave themselves, and they’re done. The stylesheets did have a little more to them, but it wasn’t what people actually cared about… and in some cases they were better off without them. I know I disagree with quite a few of their opinionated styles.
Those old browsers are now long obsolete—half of them can’t even talk TLS 1.2, which basically excludes them from the modern web—so almost all of these stylesheets is obsolete, and you don’t need them.
For the few pieces that might still have value, you would now prefer to use @layer or :where() for this kind of stylesheet, to make them behave more like user agent styles and avoid specificity conflicts.
To add to this, HTML 5/LS have a section on rendering HTML elements [1]. That section provides default CSS rules that a conforming web browser must use. Therefore, modern browsers effectively have built-in normalize.css rules, providing a consistent web page default.
There may be some rules you want to change in a set of baseline rules such as margin/padding, image sizing, and fonts. But those would be things you would add on top of normalize.css anyway.
[1] https://html.spec.whatwg.org/multipage/rendering.html#render...
Your link makes it very clear that those CSS rules are not required, that they are suggestions. However, all major browsers do use them.
In the nearly 25 years of running a web dev company, we never used such resets because it always felt like browsers had their built in settings, then one would have a reset to shift everything around one way, then we'd have settings to throw things another way and that's how it felt--like we were slamming things back and forth far too much.
Instead, we'd just set elements to what we wanted them to be which is what we'd have to do in most cases anyway, making any reset unnecessary.
This isn’t a reset, it’s normalising different browsers. There’s a pretty big difference between the two.
My point remains the same. And I'm not sure there is a difference between a reset and a normalizer.
They more or less had the same goals, different ways of achieving them.
- CSS reset - completely reset all browser styles to be blank essentially, across different browsers, so then you'll build your styling on common ground
- CSS normalize - same idea of resetting to a baseline, but keeping some of the default styling but still make it consistent across browsers, so not stripping away everything
Presumably, a reset is resetting to a browser's defaults, whereas a normaliser is about establishing a cross-browser default. I haven't done much web-dev in recent years, but I vividly remember the same page looking different in different browsers, particularly prior to HTML5.
> a reset is resetting to a browser's defaults
No, a browser's defaults are, well, its defaults. One doesn't reset to them.
I think the line between a normalizer and reset stylesheet is _very_ fine, if there even is a line. A normalizer is probably _slightly_ more opinionated than a reset stylesheet. In the end, the difference isn't really important. If you need a reset stylesheet, normalizer will probably do just as well.
I moved away from using Tailwind CSS, but still use their "preflight.css" [1]. It doesn't really care about backwards compatibility (IE stuff), but does a great job at unstyling everything so you have a clean cross-browser base to work with (button will look like text until you add your styling).
[1]: https://github.com/tailwindlabs/tailwindcss/blob/main/packag...
I took a look thinking that this might actually be useful and somehow came away with an even lower opinion of Tailwind. It’s all like this:
Why can’t they do anything reasonably? It would be easy to put code comments against the actual code it is commenting, but instead they do this weird comment index up front.Because this is how Normalize.css was written (and I suspect this is Normalize.css-derived).
that is how open source code used to be written before AI and it was appreciated, actually.
Pretty much everybody here has been coding long enough to know that is a blatant untruth.
Could you write a few words why you moved away from TailwindCSS?
I am an amateur dev (I write open-source useful for me and possibly others) and I am prone to the "front-end diarrhea syndrome", where when I see something cooler, I jump on it and regret afterwards the time spent.
I am on TailwindCSS right now and I am afraid to learn the drawbacks, but one must be courageous in life.
https://colton.dev/blog/tailwind-is-the-worst-of-all-worlds/
This is a pretty good post.
In general, I don't think `class` is a good place for styling.
Thank you, this is a nice post. On the other hand, the author is happy to have HTML and CSS generated with JS, which is weird as well (I know - React).
It has some good points (and vanilla-extract IS awesome), but it's also a bit unfair, eg ignoring tailwind affordances like `apply`.
That said, for learning the "right" way to think about and use CSS, https://every-layout.dev is hands-down the best resource I've encountered in my 20+ years working with websites.
This is actually an awesome post, thank you for sharing
What a terrible article! The author is so very ignorant, but presents themselves as an expert :(
I barely got into the "dunking" on Tailwind when I saw this.
> If you misspell one of these plain strings your editor is not going to tell you.
Ummm ... sure, if you're one of the 1% of devs who refuse to use a linter. Either the author is part of that 1%, or maybe they just weren't aware of Tailwind's linting capabilities (https://tailwindcss.com/blog/introducing-linting-for-tailwin...).
Now, to be fair, they wrote the article in 2025, and Tailwind linting was only released five years prior (in 2020) ... five years is hardly long enough to learn relevant tech for your industry /s
The rest of the article seemed similarly ill-informed, with the author fixating on meaningless byte-size differences in contrived examples. However, he ignores the fact that Tailwind is used on some of the most performant sites on the Internet. He also ignores the fact that (for 99% of sites at least) sacrificing a k or two of bandwidth is well worth it for a major increase in developability.
With Tailwind you completely get rid of stylesheets: that alone is huge! There's a reason why so many devs use Tailwind: they don't worry about minimal file size differences, but they do care about massive savings in development time and complexity reduction.
Personally I prefer Sindre Sorhus’s modern-normalise, which is gradually deleting itself as browser compatibility issues are resolved: https://github.com/sindresorhus/modern-normalize
Kind of a bummer it only targets the latest version of browsers. I get trying to remove cruft by not trying to support older versions, but if you only support the latest you're targetting a smaller % of browsers.
Actually, there are two normalizes. The first was: https://github.com/necolas/normalize.css
I chose to share the one that seemed more recent/maintained.
Brief history/explanation from: https://github.com/csstools/normalize.css/#differences-from-...
> Nicolas Gallagher and I started writing normalize.css together. I named and created the normalize.css repository with the help of Paul Irish and Ben Alman. I transferred the repository to Nicolas, who turned it into a “household” CSS library.
> Later, I resumed authorship of normalize.css with Luciano Battagliero. Together, we tagged, deprecated, and removed “opinionated” styles — styles developers often prefer but which do not fix bugs or “normalize” browser differences.
> Later, Nicolas resumed authorship and the issue of whether to include or omit the opinionated styles forced us to split.
And now there is a third variation, sanitize.css, which is the one I decided to use: https://github.com/csstools/sanitize.css
Used here: https://github.com/Leftium/news/blob/0d507aecd05dfe94853d278...
At some point I stopped caring about backwards compatibility, but I can’t put my finger on it.
Perhaps connectivity became so good that now as long as it works on evergreen, it’s good to go. We used to put a lot of effort into this stuff, but it feels like it’s been years since we even thought about it.
It's when IE 11 was deprecated, and everyone moved to well supported CSS and HTML5 browsers - modern Webkit/blink/Gecko browsers.
Ive always found this explanation helpful for why these are useful:
https://www.joshwcomeau.com/css/custom-css-reset/
I found Bootstrap's reboot.css to be a better maintained version of this.
More details here: https://getbootstrap.com/docs/5.3/content/reboot/
Code: https://github.com/twbs/bootstrap/blob/v5.3.8/dist/css/boots...
I always preferred to use sanitize.css, which is the same thing except it also makes sure everything looks pretty good.
https://csstools.github.io/sanitize.css/
At this point, writing a reset is kind of rite of passage for a web developer.
Here’s mine[1] which I wrote while working on multilingual projects involving both Latin and non-Latin languages.
[1] https://github.com/Microflash/preset/blob/main/src/preset.cs...
Obviously we can't break backwards compatibility, but why doesn't css have opt-in "use version" strings that could tell the browser: I want this set of defaults. Something like "use-defaults: system-ui;" or "use-defaults: none".
You can always do something like:
But then you’d have to reimplement everything from browser defaults, which can get a bit tedious.I agree, it would be nice to get a bit of a cleaned up set of defaults though, and you could polyfill it this way.
Why is Normalize.css back in the spotlight after all this time?
My take on Normalize.css is how something so simple can have such a huge impact. It's astonishing.
Looks unmaintained, last release 2 years ago. The website points at v11 when the most recent release is v12. Has nothing changed in browsers to necessitate code changes?
The npm install text overflows horizontally for me on iPhone 16
It does that in Firefox at certain window sizes, too, supporting its claim to consistency across major web browsers.
iP 15 Pro, Safari, same xD
iP 12 runofthemill, Orion, same
Now ui libraries does its own reset. The no-nonsense blogger just use a few styling, and yeah, the default now is good enough.
CSS is a monster, and it just keeps growing. If one wants to do something truly visually crazy / innovative / impressive, just use canvas. Didn't Google Docs abandon CSS and go straight with canvas? The feature creep in CSS is distasteful. The counter argument is if we keep adding features that will keep the LLMs at bay as they are not good at extrapolation and / or stuff they have not seen before. rant over.
Seems way too much work to completely recreate an accessibility tree as well as the rendering framework.