Re: [csswg-drafts] [css-mixins-1] A var()-based model for mixin parameters (#12927)

As noted in the OP, this new model *does* answer how  to handle things like `@apply --foo(var(--bar));`; it inverts into a custom function that is passed the same arg. This, however, has the exact same issue that the current spec does (as noted in [the Mixin Args section, between example 15 and 16](https://drafts.csswg.org/css-mixins/#mixin-args) and [explained more fully in Example 16](https://drafts.csswg.org/css-mixins/#example-399711fd) with some workarounds): any values that resolve differently based on the element they're used on (`var()`, `attr()`, `em` values, etc) will resolve based on what element the mixin actually puts them on, rather than on the element the mixin is `@apply`'d from.

This kinda sucks, but in discussion with Anders, I think we can have a partial solution. *Most* Mixins will be only styling the `@apply` element and its children/descendants/pseudos; they'd be completely unaffected by *assuming* they're scoped (a la `@scope`). *If* we assume they're scoped, we can rely on inheritance to do *hygienic renaming* (explained in <https://github.com/w3c/csswg-drafts/issues/12909#issuecomment-3400577072> by Anders) and get the values to correctly resolve based on the `@apply` element, regardless of where they're eventually used. ([Example 16](https://drafts.csswg.org/css-mixins/#example-399711fd) has an example of doing this by hand, as a workaround.)

So, what if we just declared that Mixins *were* scoped by default - that is, rather than the mixin body being a CSSNestedDeclarations, it's a CSSScopeRule, and any nested style rules in the body were scoped to the `@apply` element? Then we can do the "store the argument as an unobservable variable on the `@apply` element, and rewrite references to use that instead" transform automatically. This would also enable some things that are *impossible* to do by hand, like allowing `@apply --mixin(var(var(--var-name)));` to work (because we *know* it has be rewritten to a hygienic reference, and can carry that information around until the inner var() is actually resolved).

Then we can have a keyword on the `@mixin` rule that opts out of that, and also turns off the hygienic rewriting, for when you do want to do a Mixin that styles parents or siblings or something.

-- 
GitHub Notification of comment by tabatkins
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/12927#issuecomment-3403954934 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 23:20:06 UTC