How I'm writing CSS in 2024(leerob.io)
leerob.io
How I'm writing CSS in 2024
https://leerob.io/blog/css
36 comments
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.
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.
(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.
> ¹: 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).
Not sure if OP talks about CSS or just some JavaScript supporting invalid CSS styles.
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).
> 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).
Why would I need type safety for my CSS?
Good editor support/autocomplete, probably.
Oh nice, I didn't know this.
This page crashes my safari and Chrome tab instances on my iPhone
Had strange behavior as well on iPhone, couldn’t finish the post because it kept jumping around
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.
Might just remove the embedded sandboxes. They're cool, but not needed.
Did you find anything?
How I write CSS in 2024: Tailwind.
One last reason to use Sass would be parameterized media queries.
Could you share an example where you'd want this? Genuinely curious, haven't used these before.
I thought media queries were on the outs for flex/grid layouts and container queries?
I think media queries will still be used for a long time, but yeah container queries are a great addition on top.
kinda needed if you want to make a nice 'print' view.
Container queries have the same issue.
mixins and placeholders are still enormously useful
And nested CSS, although it’s coming to CSS soon.
& nesting selector already has a baseline support: https://developer.mozilla.org/en-US/docs/Web/CSS/Nesting_sel...
[deleted]
I haven't had to scale this to a mega-app, but most CSS doesn't.