Re: [csswg-drafts] [css-mixins-1] Alternatives to using a scoping rule (#13727)

> Perhaps there was a misunderstanding? Arguments would be available everywhere anyway; inheritance is not needed for that. We introduced scoping _only_ due to hygienic rewrites.

I wonder if we're using "scoping" differently? I'm not talking about hygiene at all. I'm talking about mixins having to return a scoped style rule. AFAIK that's not necessary for getting hygiene? You can conceptually just rewrite variables to unobservable names that are guaranteed not to clash.

As a result of mixins returning a style rule, certain rules in `@result` are silently dropped (basically anything outside the element the mixin is applied on and its descendants). I don't think this is an acceptable tradeoff. Look at the polls I posted: practically **nobody** expects this. People focused on the 100,100,100 vs 100,200,300 but the main thing I wanted to test was whether dropping the sibling selector was natural. It is not. **At. All.**

It also seems we need to get alignment first on what behavior would be ideal, if implementation constraints were not an issue, then see what are the best semantics we can reasonably implement. We're arguing tradeoffs before we have consensus on what behavior we're reducing _from_!

E.g. **I think it should be a non-negotiable that siblings etc cannot be dropped.**  If we can get 100px,100px,100px somehow, with that constraint in place, even better. E.g. perhaps there is a way to not inject these declarations on element descendants, but only on the element itself and any elements outside its subtree, which would give you the current behavior for subtrees but wouldn't drop anything.

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


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

Received on Friday, 27 March 2026 13:55:44 UTC