Re: [csswg-drafts] [css-mixins-1] Expose locals inside apply's contents block (#12631)

> `tomato`, in that example

:thumbsup:

> [red-green-blues example]
> (note that I've fiddled with the example above a lot, so don't trust what you saw in the email)

OK, that behavior makes a lot of sense to me (as it appears at the time of me writing this).

Except that you missed a spot: Duplicate `--2d` declarations.

---

Trying to imagine how this would actually be implemented:

I doubt we'll want to think of this as "rewrites", but rather as a given `var()` finding its target well. All of `--[1,2,3][1,b,c]` will resolve under the same stack frames:

 * `[2] (top)` `@apply --blues() using --b --c --d`
    * `--a: cornflowerblue;`
    * `--c: blue;`
    * `--d: navy;`
 * `[1]` `@apply --greens() using --b --c --e`
    * `--a: darkgreen;`
    * `--b: green;`
    * `--c: olive;`
 * `[0] (bottom)` `the element`
    * `--a: red;`
    * `--b: crimson;`
    * `--c: firebrick;`
    * `--d: tomato;`
    * `--e: orangered;`

So if we consider `--c*`, for example, we'll need to remember where the declaration came from:

```
--c3: var(--c); /* My origin is stack frame [2] */
--c2: var(--c); /* My origin is stack frame [1] */
--c1: var(--c); /* My origin is stack frame [0] */
```

Then, to resolve a `var(--c*)`, we return the value `--c*` as of the "target frame", which is the top-most frame with an unbroken deferral chain back to the origin frame. Basically, _skipping_ the right number of frames, and then looking up normally from there.

This feels doable, but it adds _even more_ complexity. If it's not very critical, then we should defer this `using` functionality to the next level.

-- 
GitHub Notification of comment by andruud
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/12631#issuecomment-4130223097 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Wednesday, 25 March 2026 22:23:41 UTC