Re: [csswg-drafts] [css-mixins-1] Scoped mixins (#13113)

> do we literally apply scope

Especially if mixins are scoped by default, I think we should only apply _scoping_, and not mess with specificity/proximity. If the author wants that, they can literally use `@scope` inside the mixin, or at the `@apply` side.

> Even with scoped functions, that can be achieved by changing which element the mixin is applied to – scoped selectors can reference previous siblings as context, and parent elements could put all siblings within a scope. That's likely to trip people up at first, but it's teachable.

So are you thinking that we maybe don't need unscoped mixins at all? Instead of having _unscoped_ mixins, just lift the scope? E.g. `.foo { @apply --m(); }` => `:has(> .foo) { @apply --m(); }`.

> There's also an accepted proposal for `@sibling-scope` (or something like that), but the issue here isn't actually related to scope-ability - we're only using scope as a stand-in for inherit-ability. So I don't think that helps.

Yeah, this "hygienic rewrite" _cannot_ be done in the general case because it can create cycles, e.g. a parent style depending on a child style:

```
@mixin --m() {
  .parent:has(&) {
    /* ... */
  }
}

.child {
  @apply --m();
}
```

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


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

Received on Tuesday, 18 November 2025 08:59:23 UTC