* {
all: unset;
}
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.
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.
More details here: https://getbootstrap.com/docs/5.3/content/reboot/
Code: https://github.com/twbs/bootstrap/blob/v5.3.8/dist/css/boots...
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.
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.
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.
"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.
- 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
[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.
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.
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.
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.
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
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.
/*
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 */
}
My take on Normalize.css is how something so simple can have such a huge impact. It's astonishing.
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...
reconnecting•3mo ago
Leftium•3mo ago
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•3mo ago
Used here: https://github.com/Leftium/news/blob/0d507aecd05dfe94853d278...