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

> > I have some concerns about assuming mixins can only impact descendants - though it certainly does help sidestep the question of where variables resolve.
> 
> Right, we definitely need to _allow_ affecting non-descendants, you just won't get the nice var()/em/attr()/etc behavior if you opt into that. It's a tradeoff the author has to make: hygienic arguments, or unscoped application.

Previously (off-GitHub), we talked about `@mixin unscoped --m()`, but perhaps it makes more sense to do it on the `@apply` side? E.g. `@apply unscoped --m(1em)` could make it more "locally obvious" that your `1em` is going to be affected by the `unscoped`.

> > If we do assume this, then :scope in a mixin refers to the applying element?
> 
> I suppose so, for consistency. Probably not strictly required, but I don't think it matters much either way.

Wait, in my mind this is strictly required and we don't have any other choice. What am I missing here? What do we mean by "applying element"?

In case it helps reveal what I didn't get, this example:

```
@mixin --disclose {
  button[aria-expanded="false"] + & {
    display: none;
  }
}

.show-hide { @apply --disclose; }
```

would (in a scoped-by-default world) desugar to something like:

```
@function --f1() {
  result: none;
}

.show-hide {
  @scope (&) {
    button[aria-expanded="false"] + & {
      display: --f1();
    }
  }
}
```


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


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

Received on Wednesday, 15 October 2025 21:54:45 UTC