- From: Tab Atkins Jr. via GitHub <noreply@w3.org>
- Date: Fri, 20 Mar 2026 18:07:33 +0000
- To: public-css-archive@w3.org
I think we should indeed consider the previous discussions more or less moot, at least from a technical perspective, since the model has changed significantly.
My *intuition* right now is that the contents block should act the same as arguments and resolve all variables based on the applying element. That is, in the following:
```css
div {
--a: gold;
--b: black;
--c: yellow;
@apply --bar(var(--a)) {
--color-from-element: var(--a);
}
}
```
...both the argument and `--color-from-element` would see `gold`. I think it would be confusing if one of them resolved to `gold` from the element and the other resolved to a different color from the mixin. The contents block is similar to an argument both conceptually (it's just a rule rather than a value) and visually (for both, the value is written right there inside the applying rule). There is currently *no way* to define an argument value that includes local vars from a mixin, even if you know the local var's name and there are no clashing names on the outside.
-------------
I'm cool with having an opt-in for particular variables (or all of them) to be late-resolving in the contents block. (That is, the specified variable names will try to hygienically rename themselves to match the name of an arg or local var in the mixin.)
The remaining question, then, is exactly *which* mixin scope they eventually attach themselves to.
In your chained contents example, if you changed the `div` rule to say:
```css
@apply --bar() using --a {
--color-from-element: var(--a);
}
```
I could see three options:
* (a) Use the `--a` from `--bar()`, the mixin it's being passed to.
* (b) Use the `--a` from `--bar()` by default, but `--bar` could say `using --a` in its own `@apply --foo()` to make it retarget to `--foo()`.
* (c) Use the `--a` from `--foo()`, the ultimate resting place of the style?
My intuition leans me towards (b), as that feels like it's the most consistent model, but it does mean that `--bar()` needs to know whether or not it should specify `using` to retarget variables it can't even see. "Wrapper" mixins that just adjust a second mixin would probably need to know they should default to `using all`.
--
GitHub Notification of comment by tabatkins
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/12631#issuecomment-4100037404 using your GitHub account
--
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Friday, 20 March 2026 18:07:34 UTC