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.
rhdunn [3 hidden]5 mins ago
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.
Your link makes it very clear that those CSS rules are not required, that they are suggestions. However, all major browsers do use them.
assimpleaspossi [3 hidden]5 mins ago
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.
chrismorgan [3 hidden]5 mins ago
This isn’t a reset, it’s normalising different browsers. There’s a pretty big difference between the two.
assimpleaspossi [3 hidden]5 mins ago
My point remains the same. And I'm not sure there is a difference between a reset and a normalizer.
CaptainOfCoit [3 hidden]5 mins ago
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
Defletter [3 hidden]5 mins ago
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.
Octoth0rpe [3 hidden]5 mins ago
> 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.
simjnd [3 hidden]5 mins ago
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.
zinekeller [3 hidden]5 mins ago
Because this is how Normalize.css was written (and I suspect this is Normalize.css-derived).
BrandoElFollito [3 hidden]5 mins ago
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.
In general, I don't think `class` is a good place for styling.
BrandoElFollito [3 hidden]5 mins ago
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).
pacha3000 [3 hidden]5 mins ago
This is actually an awesome post, thank you for sharing
aetherspawn [3 hidden]5 mins ago
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.
anilgulecha [3 hidden]5 mins ago
It's when IE 11 was deprecated, and everyone moved to well supported CSS and HTML5 browsers - modern Webkit/blink/Gecko 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.
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".
JimDabell [3 hidden]5 mins ago
You can always do something like:
* {
all: unset;
}
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.
ugur2nd [3 hidden]5 mins ago
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.
croemer [3 hidden]5 mins ago
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?
fred_ [3 hidden]5 mins ago
The npm install text overflows horizontally for me on iPhone 16
defanor [3 hidden]5 mins ago
It does that in Firefox at certain window sizes, too, supporting its claim to consistency across major web browsers.
misiek08 [3 hidden]5 mins ago
iP 15 Pro, Safari, same xD
jgalt212 [3 hidden]5 mins ago
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.
kuekacang [3 hidden]5 mins ago
Now ui libraries does its own reset. The no-nonsense blogger just use a few styling, and yeah, the default now is good enough.
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.
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...
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.
- 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
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.
[1]: https://github.com/tailwindlabs/tailwindcss/blob/main/packag...
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.
This is a pretty good post.
In general, I don't think `class` is a good place for styling.
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.
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.
Used here: https://github.com/Leftium/news/blob/0d507aecd05dfe94853d278...
https://www.joshwcomeau.com/css/custom-css-reset/
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...
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 agree, it would be nice to get a bit of a cleaned up set of defaults though, and you could polyfill it this way.
My take on Normalize.css is how something so simple can have such a huge impact. It's astonishing.