All good!

I don’t see how a class name hash is different to what @scope can express

I’m not sure I understand the use case, but also I’m curious how you solve this with css modules?

This would also be quite trivial for a build tool to accomplish. It could make a `Foo.css` of `p { background: red }` emit `@scope ...` with just a text transform, rather than building an AST to parse `:global` and such.

(You can also do this with classes if you'd prefer): <div class="Component Foo"> <Component class="Component Bar"> <p>Nested child</p> </Component> <p>Child</p> </div> @scope (.Component.Foo) to (.Component) { p { background:red } }

If you wanted to solve this generally, you could do e.g: <div data-component=Foo> <Component data-component=Bar> <p>Nested child</p> </Component> <p>Child</p> </div> @scope ([data-component=Foo]) to ([data-component]) { p { background:red } } This would avoid styling nested components

Curious on your takes also!

Name mangling is tricky to debug and can cause unnecessary cache thrashing (depending on toolchain it'll re-compute hashes when JS and/or CSS change). I also don't like non-standard extensions to CSS. I think (though have no empirical practice/data) that css `@scope` would solve the use case.

They are decoupled because the CSS remains static and does not get recomputed/re-evaluated by JS when the state changes. Svelte encourages CSS Custom Properties (which separate concerns). Other css-in-js libraries encourage you to use e.g. template literals (which does not separate concerns).

No. It's about coupling. You are initially correct that it's an architecture pattern. It is about decoupling presentation layer from the behavioural one. But you go on to say svelte does not have this quality. From what I have seen of svelte, it does have this.

You may be misunderstanding separation of concerns then.

On one end of the extreme, teams author one single css file and that’s obviously untenable (even engines have different css). On the other people are radically eschewing the entire concept, but that’s against the grain of the platform and so equally untenable.

It depends on your interpretation of “strict separation”. I think collocation is fine. Especially say for eg the way svelte handles it, because it still maintains separation of concerns. Even having a string of css in a js file separates the concerns (to a degree).

I don't think css modules are the way forward, and when I say "but we're still not using css. Just use css!" I'm told I'm not being realistic, and so back on the merry-go-round we go. I don't understand how people who keep offering new solutions retain trust.

I grieve the post-facto reasoning. Opponents of a "good solution" are deemed wrong until proven right, then that was always the case. styled-components was touted as "good" by proponents, but we had to FAFO, then those same proponents turn and say "that was always bad. But <X> is good!".