A week ago, we put out a poll asking how many Sass users wrote CSS custom properties that weren't also valid SassScript (https://front-end.social/@sass/115272830411739760). About a third of you said you did, but no one gave examples. We'd love to know the specific use-cases you have for custom properties that use syntax that wouldn't be valid in other CSS properties!
In Sass today, CSS custom properties are parsed differently than other declarations. They don't allow normal SassScript—any variables and custom functions have to be wrapped in #{}. This is because the spec allows *anything* there, and it can be read from JS. But we're wondering: does anyone actually use this in practice? Remember that any value for any non-custom property is also valid SassScript. (Please share for broader reach!)
[ ] I write CSS vars that aren't valid SassScript
[ ] All my CSS vars are valid SassScript
[ ] I don't use CSS vars/show results
In Sass today, CSS custom properties are parsed differently than other declarations. They don't allow normal SassScript—any variables and custom functions have to be wrapped in #{}. This is because the spec allows *anything* there, and it can be read from JS. But we're wondering: does anyone actually use this in practice? Remember that any value for any non-custom property is also valid SassScript. (Please share for broader reach!)
If you write CSS vars that aren't valid SassScript, we want to know details! Please reply with an example of the sorts of variables you're writing and why.
If we do change the way custom properties are parsed, it will be far in the future after a full deprecation cycle to make sure anyone who's using anything weird has a chance to migrate to something compatible. The main question right now is how we parse the `result` property in CSS `@function` rules, which has the same considerations as custom properties.
In Sass today, CSS custom properties are parsed differently than other declarations. They don't allow normal SassScript—any variables and custom functions have to be wrapped in #{}. This is because the spec allows *anything* there, and it can be read from JS. But we're wondering: does anyone actually use this in practice? Remember that any value for any non-custom property is also valid SassScript. (Please share for broader reach!)
We've got another proposal out for review, and this one's meaty! It proposes adding Sass support for the new plain CSS if() function in place of Sass's old if() function syntax. Let us know what you think! https://github.com/sass/sass/blob/main/proposal/plain-css-if.md
sass/proposal/plain-css-if.md at main · sass/sass
Sass makes CSS fun! Contribute to sass/sass development by creating an account on GitHub.
We've got another proposal for people to review! This one slightly changes the logic of which function names are reserved to better match CSS semantics and un-reserve some functions that are generally safe: https://github.com/sass/sass/blob/main/proposal/function-name.md
sass/proposal/function-name.md at main · sass/sass
Sass makes CSS fun! Contribute to sass/sass development by creating an account on GitHub.