Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[CSS Mixins and Functions] An alternative #35

Open
matthew-dean opened this issue Mar 14, 2024 · 1 comment
Open

[CSS Mixins and Functions] An alternative #35

matthew-dean opened this issue Mar 14, 2024 · 1 comment

Comments

@matthew-dean
Copy link

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.

@mirisuzanne
Copy link
Member

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants