This feels like a particularly bad case of 'every templating system eventually turns into a (bad) programming language'. It appears to have global+local variabl

This feels like a particularly bad case of 'every templating system eventually turns into a (bad) programming language'. It appears to have global+local variables, functions, mixins with positional and named arguments, and so on, all mashed together with the existing CSS features like media queries and nested selectors. But some of it isn't meaningful in combination, as the document itself says. I have two major objections: - There is no way that people who are currently writing conditional CSS-in-JS would switch to a system with a more obscure syntax, where they can't just use the same variables as their normal code, pull in imports from shared themes and libraries, and so on. This proposal includes basic local scoping rules, but they are a poor imitation of what we know works in real codebases. So the audience is people who use preprocessors, and who get around the lack of e.g. arrays or dictionaries by generating sequential variable names. - Once you actually add functions and imperative control flow, much of the existing CSS selector machinery becomes obsolete. Why should you wrap things in `@media`, when you could just have a variable or function to query? What is the criterium for determining whether something should be declarative or imperative? Will every feature end up being available in both forms? Why or why not? I find it particularly funny that one of the examples involves applying a 'clearfix' to an element, which is a technique from the proverbial CSS stone age. That is, they are still inserting invisible pseudo-elements to make the layout behave, which shows markup and styling are tied together anyway. The main thing CSS-in-JS lets you do is not automate this sort of style hackery, it's to create sensible wrappers and components that actually decouple layout from content in a way that is practical, stacks cleanly, and maps directly to e.g. how a designer does it in Figma. And instead of adding e.g. endless new color manipulation functions in CSS, you should use a proper library for this. Whatever argument there was for not allowing CSS to call into JS, it starts to look ever less convincing when this is the alternative. Maybe all we need is a more sensible interface between JS and CSS, perhaps something patterned after declarative frameworks. i.e. They should add a Color type to DOM APIs, instead of adding control flow to CSS.