How I'm writing CSS in 2024

I kind of prefer it the old, allegedly bad way. I just write selectors and rules in my css files. I use approximately "semantic" selectors, but I'm not religious about it. Everything seems to work pretty good.

I haven't had to scale this to a mega-app, but most CSS doesn't.

I was trying to find a definition for "css modules," which the author links but the link is self-referential. I followed a few links, and I came across this: ".jsx files support both global CSS and CSS Modules. To enable the latter, use the .module.css extension (or .module.scss/.module.sass if using Sass)."

which I would call x-dimensional rabbit holes.

I think I'll keep on with web components and the shadow DOM.

> Cross-browser support for nesting, :has(), container queries, and more¹

> ¹: More: linear() easing, subgrid, dynamic viewport units, color spaces, and @layer.

Of these: @layer has broad support from March 2022, dynamic viewport units from December 2022, but the rest have less than a year (a couple less than a month). You shouldn’t depend on any of these yet for general web content. It’s pleasant to find that no single browser is lagging behind: Chromium, Safari and Firefox are all first to implement at least one of these features by more than a year, and all last to implement at least one of these features.

(Also, a correction: the nesting link should be https://caniuse.com/css-nesting.)

—⁂—

> 1. Stylesheets should load as fast as possible (small file sizes)

> 2. Stylesheets should not re-download unless changed (proper caching headers)

There’s a fascinating contradiction in the midst of these two: inlining CSS (as in, from a <link rel=stylesheet> to a <style>) is unreasonably good for performance up to surprisingly large file sizes (I haven’t tried to get good numbers, but reckon it’s comfortably into the tens of kilobytes transferred).

If you have the ability to conveniently do it, try inlining all CSS files always, and get a feel for the performance differences. The results may surprise you.

> 4. Fonts should load as fast as possible and minimize layout shift

I would remind people that “as fast as possible” means just don’t use them. I would also remind users that you can disable web fonts: my experience is that the fallout is slight, and the advantages due to consistency significant.

—⁂—

> Specify target browsers (browserslist) and have syntax lowering to compile modern CSS features to work with those browsers

Just remember that this is primarily about syntax features like nesting selectors or rgb(r g b / a) instead of rgba(r, g, b, a). Of runtime features, it can only help with a few, e.g. adding RGB approximations for wide gamut colours, or kinda supporting logical properties like margin-inline. Things like :has(), container queries and subgrid, it can’t help you with.

It's incredible how CSS has almost become SCSS (barring some features like loops, placeholders, and mixins).

I second the author’s recommendation for CSS modules. However

> And because the styling code lives outside your TypeScript files, you don't get type safety and autocompletion.

You actually do, there’s a TypeScript plugin from CSS modules that generates types for your CSS classes (at least).

This page crashes my safari and Chrome tab instances on my iPhone

How I write CSS in 2024: Tailwind.

One last reason to use Sass would be parameterized media queries.