Skip to content(if available)orjump to list(if available)

Normalize.css

Normalize.css

19 comments

·October 21, 2025

chrismorgan

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.

rhdunn

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...

assimpleaspossi

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

This isn’t a reset, it’s normalising different browsers. There’s a pretty big difference between the two.

assimpleaspossi

My point remains the same. And I'm not sure there is a difference between a reset and a normalizer.

simjnd

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...

aetherspawn

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

It's when IE 11 was deprecated, and everyone moved to well supported CSS and HTML5 browsers - modern Webkit/blink/Gecko browsers.

reconnecting

Actually, there are two normalizes. The first was: https://github.com/necolas/normalize.css

Leftium

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.

Leftium

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...

croemer

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?

johnnypangs

Ive always found this explanation helpful for why these are useful:

https://www.joshwcomeau.com/css/custom-css-reset/

fouronnes3

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".

fred_

The npm install text overflows horizontally for me on iPhone 16

defanor

It does that in Firefox at certain window sizes, too, supporting its claim to consistency across major web browsers.

misiek08

iP 15 Pro, Safari, same xD

maxloh

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...

kuekacang

Now ui libraries does its own reset. The no-nonsense blogger just use a few styling, and yeah, the default now is good enough.