Normalize.css

Posted3 months agoActive2 months ago

Leftium

69 points

54 comments

csstools.github.ioTechstory

calmmixed

Debate

40/100

CSSWeb DevelopmentNormalize.css

Key topics

CSS

Web Development

Normalize.css

The discussion around Normalize.css, a CSS reset library, highlights its continued relevance and the evolution of CSS reset approaches in modern web development.

Snapshot generated from the HN discussion

Discussion Activity

Very active discussion

First comment

Peak period

Day 5

Avg / period

Comment distribution54 data points

Loading chart...

Based on 54 loaded comments

Key moments

01Story posted
Oct 20, 2025 at 9:42 PM EDT
3 months ago
Step 01
02First comment
Oct 25, 2025 at 2:46 AM EDT
4d after posting
Step 02
03Peak activity
47 comments in Day 5
Hottest window of the conversation
Step 03
04Latest activity
Oct 31, 2025 at 5:11 PM EDT
2 months ago
Step 04

Generating AI Summary...

Analyzing up to 500 comments to identify key contributors and discussion patterns

Discussion (54 comments)

Showing 54 comments

reconnecting

2 months ago

2 replies

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

LeftiumAuthor

2 months ago

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

LeftiumAuthor

2 months ago

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.

fouronnes3

2 months ago

1 reply

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

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

aetherspawn

2 months ago

1 reply

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

2 months ago

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

fred_

2 months ago

2 replies

The npm install text overflows horizontally for me on iPhone 16

defanor

2 months ago

2 replies

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

MonaroVXR

2 months ago

Same for me to, using Microsoft Edge on Android 16 using a Pixel 8

DANmode

2 months ago

No better laugh than an HN laugh.

misiek08

2 months ago

1 reply

iP 15 Pro, Safari, same xD

mediumsmart

2 months ago

iP 12 runofthemill, Orion, same

chrismorgan

2 months ago

2 replies

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

2 months ago

1 reply

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

extra88

2 months ago

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

2 months ago

1 reply

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

2 months ago

1 reply

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

assimpleaspossi

2 months ago

2 replies

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

Defletter

2 months ago

2 replies

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

2 months ago

1 reply

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

efilife

2 months ago

The line is not fine. Resets don't apply any styling, normalizers do. Normalizers keep the overall styling, like the margins of paragraphs and set them to an arbitrary value so all browsers will act the same. A reset is usually just: * { all: unset; }

assimpleaspossi

2 months ago

1 reply

None of that matters. Just set the properties you want the element you are using to what you want it to be. No need to think about any other elements except the ones you use and, when you set a property, it will be the same across all browsers. No need to give it a name or import it into your style sheet.

No thinking involved at all outside of your normal design method. No need to investigate the latest trends or activities by some online guy. Just do what you do.

Defletter

2 months ago

> Just set the properties you want the element you are using to what you want it to be.

"Just". What I remember from that time was putting a button at relative 0,0 and it being at the top-left of the page in one browser, but was offset in another because that browser was adding padding/margin to <body>. I cannot say which was "correct" but it nonetheless pushed me to use normalisers, which prevented this kind of problem from ever coming up again.

CaptainOfCoit

2 months 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

simjnd

2 months ago

2 replies

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

BrandoElFollito

2 months ago

2 replies

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.

alt187

2 months ago

4 replies

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.

BrandoElFollito

2 months ago

2 replies

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

llbbdd

2 months ago

1 reply

Why is that weird?

BrandoElFollito

2 months ago

Because his article is about bringing back CSS to its glory (more or less :)) and at the same time is happy with his HTML being generated by JS. Instead of having a pure semantic HTML section.

I am not saying that is good or bad (I use Vue for instance), just a bit contradictory.

But that's nitpicking on my side.

alt187

2 months ago

I agree, I like my CSS good and saved in a .css file.

hungryhobbit

2 months ago

1 reply

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.

spoiler

2 months ago

You described a lot of orthogonal points and highlighted your opinions, more than pointed out flaws in the article.

I use Tailwind at work at a large company, and it's... Okay. Its biggest strength is the documentation, since most companies have poorly documented style guide/component library.

I'd never use it for a personal project though. It's fine to disagree

chrisweekly

2 months ago

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.

pacha3000

2 months ago

This is actually an awesome post, thank you for sharing

simjnd

2 months ago

I find it just inevitably leads to massive classes that pollute markup. Makes it a lot harder to parse HTML and figure out the structure. There are ways to make it a bit better but it's still not great (for me).

It's even worse with conditional styling since you're not toggling a single class on an off but dozens.

You can't use string interpolation for classes, e.g. `<div class={`bg-${color}-400`}>` (Tailwind won't include the classes in your CSS because it doesn't recognize you want all or a subset of bg-<color>-400 classes. They recommend using maps but this becomes very verbose once there are more than a few options.

``` const colorMap = { 'red' : 'bg-red-400', 'blue': 'bg-blue-400' } <div class={colorMap[color]}></div> ```

I'm using Svelte which has a great built-in styling solution with component-scoped styles by default, and modern CSS with nesting is a lot more compact than it used to be.

JimDabell

2 months ago

2 replies

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.

brazukadev

2 months ago

1 reply

that is how open source code used to be written before AI and it was appreciated, actually.

JimDabell

2 months ago

Pretty much everybody here has been coding long enough to know that is a blatant untruth.

zinekeller

2 months ago

Because this is how Normalize.css was written (and I suspect this is Normalize.css-derived).

jgalt212

2 months ago

1 reply

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.

robin_reala

2 months ago

Seems way too much work to completely recreate an accessibility tree as well as the rendering framework.

robin_reala

2 months ago

1 reply

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

jszymborski

2 months ago

1 reply

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.

socalgal2

2 months ago

1 reply

What’s the percentage?

jszymborski

2 months ago

Depends what "latest" means, but eyeballing this table quickly, often much less than 10%

https://caniuse.com/usage-table

microflash

2 months ago

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

sholladay

2 months ago

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/

kuekacang

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

ugur2nd

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

johnnypangs

2 months ago

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

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

croemer

2 months 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?

maxloh

2 months ago

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

View full discussion on Hacker News

ID: 45651554Type: storyLast synced: 11/20/2025, 3:50:08 PM

Want the full context?

Jump to the original sources

Read the primary article or dive into the live Hacker News thread when you're ready.

Open link View on HN