- From: Tab Atkins Jr. via GitHub <noreply@w3.org>
- Date: Tue, 14 Oct 2025 18:25:00 +0000
- To: public-css-archive@w3.org
*Ignoring Mixins for the moment*, there's absolutely nothing wrong with these ideas. The inability to store a function name in a variable and call it is purely an accidental syntactic restriction, not a meaningful one, and we could solve that in multiple ways. (I lightly favor that `call(fn-name, arg1, arg2, ...)` syntax.)
Variable mixins are just fully impossible as currently written. That would mean *entire rule structures* couldn't be determined until computed value time, when variables are finally replaced. It's also intrinsically cyclic, because the mixin might set that exact var on the element's parent! We currently can track cycles and cut them off because all of the dependency information is known as we resolve functions; if we can introduce whole new rules as a result and have to restyle, that would require us to instead invoke some sort of "versions" layering for variables, where they could have different values at different times on the same element. Just an enormous amount of confusing complexity that would still only half-work, I believe.
A more restricted version of a Mixin would allow it, tho - if you were guaranteed that the "mixin" was just declarations, no nested style rules, it would be okay. Effectively a shorthand, in other words. We could make this sort of weaker construct explicit in level 2, if we wanted, an `@shorthand --foo(....) {...}` rule that maybe gets invoked differently.
--
GitHub Notification of comment by tabatkins
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/12806#issuecomment-3403098698 using your GitHub account
--
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Tuesday, 14 October 2025 18:25:01 UTC