- From: Miriam Suzanne via GitHub <sysbot+gh@w3.org>
- Date: Fri, 13 Jan 2023 20:01:28 +0000
- To: public-css-archive@w3.org
Yes, I've had use-cases for both selectors – but the desire to 'scope the outer selector entirely' (`.c .a .b` in the example above) is by far the majority use-case in my experience, and what I would expect from reading the selector. I would find it fairly surprising to get the `.c :is(.a .b)` behavior without specifically requesting it. And I'd have a strong leaning towards the semantics that allow expressing both variations explicitly, rather than implicitly using the more broad selector without any way to clarify. I am curious how the css-nesting polyfills in other processors have handled this. Were those polyfills designed with the current spec behavior, and has that resulted in surprising selectors for people? (While I'm curious about that, I don't think it necessarily tells us if the pattern is safe. In a lot of cases, I would expect the DOM will only have `.c .a .b` matches, even when the output selector is `.c :is(.a .b)`. That wouldn't make it safe to implement the less expected behavior, it would actually point to the idea that one case is much more common. I don't think that's something we could measure. So the question is really: are people explicitly expecting and relying on the `.c :is(.a .b)` pattern when writing `.c &` in one of those polyfills?) -- GitHub Notification of comment by mirisuzanne Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/8310#issuecomment-1382329423 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Friday, 13 January 2023 20:01:29 UTC