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

Playing with the https://github.com/w3c/csswg-drafts/issues/12927's prototype, and I have a few thoughts.

First, I think that the problem with overriding the outer custom properties from inside can be even more pronounced:

```CSS
@mixin --test(@contents) {
  --foo: pink;
  @contents;
}

button {
  --foo: lightgreen;
  @apply --test {
    background: var(--foo);
  }
}
```

Without knowing the implementation details of the `--foo` mixin, the author might think that the background will be lightgreen, but it will be pink.

That said, mixins being able to apply custom properties already makes this awkward regardless, even without considering the `@contents`. The above can also be thought of as:

```CSS
@mixin --test() {
  --foo: pink;
}

button {
  --foo: lightgreen;
  @apply --test;
  background: var(--foo);
}
```

With the background being obviously pink.

In both these cases, the author has control over what should take priority by moving their `--foo` _after_ the `@apply`:

```CSS
@mixin --test(@contents) {
  --foo: pink;
  @contents;
}

button {
  @apply --test {
    background: var(--foo);
  }
  --foo: lightgreen;
}
```

Now, the background will be lightgreen, as the button's `--foo` will override the `--foo` from inside the mixin (unless it is still higher in the cascade inside the mixin, due to importance or just added specificity).

This feels pretty awkward, but I am not sure if we can do anything about this, really. And this issue will be there regardless of if we use an `env()`- or `var()`-based model, as this is just regular custom properties.

Unless we make _all_ custom properties inside a mixin local by default?

- - -

That said, I was also able to check that the local variables inside a mixin work already (as `@local` is not implemented, used the default arguments for this): 

```CSS
@mixin --test(@contents, --foo: pink) {
  @contents
}

button {
  @apply --test {
    background: var(--foo);
  }
  --foo: lime;
}
```

This works and will be pink! The `background` outside of the `@apply` does not see the inner `--foo`, but when inside the `@apply` it does, and it takes precedence over whatever is outside of `@apply` regardless of the order (I guess, due to the hypothetical element model?)

The following will be lightgreen, as expected, as the outer and inner `background` get different `--foo` values, and the outer overrides the inner:

```CSS
button {
  --foo: lightgreen;
  @apply --test {
    background: var(--foo);
  }
  background: var(--foo);
}
```

Given there is already an issue with the regular custom properties and them being potentially overridden from inside the mixin regardless of the model, I am not sure we should do anything special for the local variables available this way? Unless, again, we solve this via making all the mixin's custom properties local by default, then there will be a reason to define some way to get the local variables inside the `@apply` block.

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


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

Received on Wednesday, 12 November 2025 14:09:51 UTC