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".
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.
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.
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).
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.
16 comments
[ 6.4 ms ] story [ 30.2 ms ] threadPerhaps 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...
https://www.joshwcomeau.com/css/custom-css-reset/
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.
[1]: https://github.com/tailwindlabs/tailwindcss/blob/main/packag...
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...
https://csstools.github.io/sanitize.css/