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.
ok, functionally kind of like Shadow DOM, but requires a compile step (which interacts with other compile steps and libraries in different ways I guess), and re-invents all the shadow DOM facilities like referencing local elements but with those x-dimensional provisos.
In my opinion, all of these things exist because CSS is confusing to people, not because anything is inherently better. This is especially true with modern build tools. CSS modules and Atomic CSS seem like a regression to me, but not all needs are the same.
> 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.
> 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.
Trying to debug this right now, had similar reports. It's something with my CodeSandbox embeds (through Sandpack). I've tried better error handling but nothing yet, based on the error I'm seeing it sounds like it's overloading the GPU. Surprisingly can't find anything in Sandpack about it.
Might just remove the embedded sandboxes. They're cool, but not needed.
I haven't had to scale this to a mega-app, but most CSS doesn't.