mirisuzanne
commented
6 months ago The goal of a css syntax would explicitly be limited to declarative functionality - taking features that already exist in CSS, and allowing them to be combined in reusable ways. That seems to me 1) exactly suited to CSS as already-present declarative language in question, and also 2) something we should consider extending with imperative worklets defined elsewhere.
The CSS-native version would also get access to a wide range of useful functions/features already built into CSS - like the ability to manipulate colors and lengths - which JS can not do very easily at this point. I don't think these proposals are at odds.
I stumbled today across the CSS Mixins & Functions Explainer. While I'm sure many who are used to Sass are used to syntax like this, it's probably my least favorite part of Sass, and it's even more strange in the context of CSS, which is not imperative.
However! My intent is not to complain about that proposal; it can be evaluated on its on merits -- however, I think a better start might be to support integration into programming languages that are already present -- namely JS and WASM (and all of the languages targeting each) in a much more efficient form -- worklets.
CSS has already established worklets as efficient little workers for CSS tasks, but have thus far assigned it to IMO the broadest-possible niche use case, which is painting an entire element. I've created a proposal here for Value Transform Worklets which would place scripting in a scripting language (rather than turn CSS into a scripting language), but integrate it efficiently with CSS. (Another benefit is that you get the entire imported ecosystem of JS / WASM without having to re-create those functions. This is effectively how Less/Jess works.)
There's probably some room to have a worklet be applied to or have access to the entire ruleset, whilst still keeping the entire scripting part of the host programming language.
Thanks for your consideration.