Why is this a wrong solution? about postcss-atomised

[sndrs]

hi @Leimi – sorry for taking so long to notice this! Thanks for your question :)

the reason it seemed like wrong solution is that it so radically re-writes your original CSS that I felt very uncomfortable shipping anything even vaguely complex without a build-step test to verify that both collections of rules would generate the same render tree.

while that must be technically possible (you ought to be able to generate a DOM based on the selectors in the original CSS to test with), at the point at which I found myself trying to write this test, i also came across styletron which solves the problem in similar but much smarter way (create the atomic sheet as you encounter declarations in your templates, not from an existing sheet).

we weren't using JS to render our HTML at that point (we use scala play) so it wasn't possible to use it, but generating only the CSS you need seems very much like the solution you'd want to arrive at, whereas reducing whatever CSS you've already got (which is very possibly more than you actually need on a given page – for us, after 4+ years of dev and a v complex design, our CSS is only 10% efficient on any given page) is potentially dangerous and only patches over the complexity.

We felt that in a way, it allows you to keep on with bad practices because it deals with the size of what you ship, but not with why what you are shipping has got so big.

Given the extra layer of complexity and confidence you'd need in what you shipped to browsers with this atomising approach, we decided we'd rather spend the time moving to SSR JS. That way we can get the benefits of a closely-coupled componentised system as well.

Does that make sense?

[wmertens]

@sndrs Hello from 2023! In the meantime, Tailwind's popularity indicates that fixed atomic CSS instead of runtime CSS-in-JS is a good idea after all :-)

I was hoping to get your feedback on something: I think you're leaving optimizations on the table, because you don't allow combined selectors, because you want to replace big classnames with their atomised names.

If however, you treat each complex selector as a separate class, you can split those combined rulesets too. You'd go from

.a { width: 3em; margin-left: 1em; height: 3em; }
.b { width: 3em; height: 5em; }
.a+.b { margin-left: 1em; color: blue; }

to

.a,.b { width: 3em; }
.a { height: 3em; }
.b { height: 5em; }
.a,.a+.b { margin-left: 1em; }
.a+.b { color: blue; }

That leaves you with:

• long classnames
• repetition in selectors

The long classnames you can fix if you have all source code available and no classnames are the result of interpolation. In that case, you make a mapping from long to short classname and replace everything in all code.

Some classes could be replaced by others if they have exactly the same rulesets: for each class that has x rules, go over all classes with x rules and see if they're all the same.

The repetition in selectors is only on the CSS side, and is already helped by compressing, but you could also recombine rules that have the same selectors (as long as they don't get overridden by another class).

Does this seem correct?