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

I suppose another question here is: do we literally apply scope, including the cascade specificity/proximity implications? My instinct is that we don't want every mixin to negate the specificity of the outside selector, so at least in that way we're not likely applying scope logic completely. Applying proximity would be a bit less surprising, but not necessarily intended here.

---

Parameters resolving on the subject-elements rather than the apply-element is pretty surprising behavior, so I doubt we want that as the default. And if a mixin author wants to resolve a value on the subject-elements, they can still do that by using non-parameter variables in the output. So I expect the main reason to want a non-scoped mixin would be the ability to target siblings?

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.

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.

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


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

Received on Monday, 17 November 2025 18:18:07 UTC