- From: Oriol Brufau via GitHub <sysbot+gh@w3.org>
- Date: Wed, 18 Jan 2023 14:10:17 +0000
- To: public-css-archive@w3.org
> as per `:has()` I don't think the current spec is inconsistent with `:has()` if that's what you mean. If you have `.a:has(.b .c)`, then it's kinda like `.a:has(& .b .c)` [*]. So it's normal that it checks for `.a .b .c`. And `.a:has(:is(.b .c))` is like `.a:has(& :is(.b .c))` so it checks for a `.a :is(.b .c)`, which is different. [*]: #7211 disallowed `&`/`:scope` in that sense, but imagine that's possible Basically, this issue only has implication on relative selectors where the reference to the anchor elements is not on the left-most compound selector, which can't happen with `:has()`. > If it remains with an implicit :is(), and there's no way to achieve the alternative within nesting, then it doesn't support what is probably the larger use case for nesting Most nested selectors have `&` at the beginning, so they are not affected by this. > easier to read naturally The natural thing is that `.a + &` selects some element preceded by `.a`. I guess that SASS has another behavior because back then `:is()` didn't exist and being a preprocessor it couldn't do better. -- GitHub Notification of comment by Loirooriol Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/8310#issuecomment-1387134522 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 18 January 2023 14:10:19 UTC