My final conclusion about CSS is - program the damn machine.<p>What I mean by this is STOP every single type of abstraction/library/programming layer for CSS - nothing gets it right, everything causes a problem.<p>The ONLY way to deal with CSS is program it directly in the way the docs say, never anything else.<p>There's nothing wrong with using Bootstrap or whatever, and I definitely use JavaScript to program CSS. What I am saying is - no abstractions - no "better way" - no trying to turn CSS into something it isn't via whatever your new abstraction is that can be added to the N other abstractions that other people have made over the years.<p>Program the damn machine.
For me nothing beats plain old classes and an external css file. For PWAs I just use lit css within the element, again with classes and plain css. If things cause problems, just figure out why and fix the classes.
This is exactly how I feel. <i>Learn</i> how to write CSS! Like you would do with any language!
This sounds interesting, but I’d need to think about it more so I could picture how things fit together as they get more complex <i>and different styles logically overlap</i>. This looks to head in the utility direction possibly too far for that to work nicely. But it may well work better than I’m initially imagining.<p>Unfortunately I can’t give it more attention now, because I should have gone to sleep a couple of hours ago…<p>—⁂—<p>Another approach entirely is to <i>embrace</i> last-declaration-wins, by :where()ing everything:<p><pre><code> :where(.t0) { background: var(--primary-color); }
:where(.t0:hover) { background: var(--primary-hover-color); }
:where(.t0:active) { background: var(--primary-pressed-color); }
:where(.t0[disabled]) { background: var(--surface-color); }
</code></pre>
I’d be interested to know which approach performs better once you have altogether too many elements and altogether too complex selectors. I suspect the :where() would win, but that the difference would be impossible to detect in any sort of realistic load.
Happy to take questions! I built this because I kept hitting the same wall: CSS state resolution is opaque when states overlap, and extending components means mentally re-deriving the whole selector matrix every time.<p>Some topics I'm curious what people think about:<p>- What’s the one thing this doesn’t cover that you’d expect it to?<p>- Does the syntax feel natural to you, or did you find yourself confused by anything?<p>- I'm looking for edge cases: what kind of complex selector scenario would trip this compiler up or be impossible to express with this model?<p>AMA—happy to answer any questions about the tool, the implementation, or the design choices.
Probably because you aren't using Sin