- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 01 Jun 2022 16:47:47 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[selectors-4] Defer complex selectors inside :nth-child() etc. to L5`, and agreed to the following: * `RESOLVED: Revert the resolution from #3760, removing the "no complex selectors" restriction from :nth-child()` <details><summary>The full IRC log of that discussion</summary> <fantasai> Topic: [selectors-4] Defer complex selectors inside :nth-child() etc. to L5<br> <fantasai> github: https://github.com/w3c/csswg-drafts/issues/3760#issuecomment-1119234126<br> <fantasai> scribenick: TabAtkins<br> <TabAtkins> fantasai: We had agreed to defer complex selector sinside :nth-child() until levle 5<br> <TabAtkins> fantasai: and :is() and :where(), etc<br> <TabAtkins> fantasai: It seems like it's been implemented in :is()/:where()/:not() tho<br> <TabAtkins> fantasai: So I committed the edits to restrict it for :nth-child()/etc, but not for the others that have already implemented it.<br> <TabAtkins> fantasai: So I want to know if we really do want this restriction for :nth-child(), or if impls are okay with just allowing complex selectors.<br> <TabAtkins> fantasai: Oriol had a question about nesting :nth-child(... of :is()), the restriction would be recursive.<br> <TabAtkins> astearns: So both those examples would b einvalid?<br> <TabAtkins> fantasai: Yes.<br> <TabAtkins> fantasai: Or both valid, depending.<br> <TabAtkins> fantasai: So question is, what do impls want to do?<br> <TabAtkins> emilio: Since Blink and Gecko don't yet implement the "of <selector>" at all yet, I'd be okay with moving it to level 5. But we should implement it.<br> <TabAtkins> fantasai: Note that this just about complex selectors in "of <selector>"<br> <TabAtkins> fantasai: Not the general feature<br> <TabAtkins> fantasai: so :nth-child(1 of .foo) would be valid in level 4, but :nth-child(1 of .foo .bar) would be invalid<br> <TabAtkins> emilio: Don't think it matters much either way. When we get to implement it we'll probably do the ocmplex selector form.<br> <bkardell_> +1 to move it to level 5<br> <TabAtkins> emilio: Guess it matters how much it matters for Selectors 4 to have multiple interoperable impls, but we don't implement the simple selector syntax either in Gecko.<br> <TabAtkins> fantasai: Opinions from the Safari team?<br> <TabAtkins> jensimmons: I think we've already implemented it<br> <TabAtkins> TabAtkins: I know Safari has done at least simple selectors, dunno about complex<br> <fantasai> https://www.software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%3Cstyle%3Ep%3Anth-child(1%20of%20body%20%3E%20p)%20%7B%20background%3A%20yellow%3B%20%7D%3C%2Fstyle%3E%0A%0A%3Cp%3Estylethis<br> <TabAtkins> astearns: In terms of spec advancement, punting complex selectors means we could promote level 4 as soon as simple selectors are done by multiple impls. But it's not clear to me if that's actually going to happen.<br> <TabAtkins> fantasai: It seems like webkit supports complex selectors in :nth-child()<br> <astearns> s/actually going to happen/actually going to happen before complex is also supported/<br> <TabAtkins> fantasai: So question is just to other impls - do you want to tackle complex selectors when you do the feature at all? Or do it stepwise?<br> <TabAtkins> futhark: Don't have thoughts about it right now.<br> <TabAtkins> emilio: Same<br> <TabAtkins> emilio: I don't see anything terrible complicated about supporting complex selectors.<br> <TabAtkins> emilio: Might make the invalidation a little trickier, but probably not by much.<br> <TabAtkins> fantasai: Okay so if we don't know, and Safari has already done it, I suggest we remove the restriction.<br> <bkardell_> ok<br> <TabAtkins> fantasai: If we need toa dd the restriction later we can do that.<br> <TabAtkins> emilio: Sounds good.<br> <TabAtkins> astearns: so proposed resolution is to undo the previous resolution and put complex selectors back into :nth-child(), until we see that this is a blocker for level 4 advancement<br> <TabAtkins> astearns: Objections to reversing the previous resolution?<br> <TabAtkins> (in issue 3760)<br> <TabAtkins> chrishtr: Rune can you confirm if this is implemented this way in Chrome at th emoment?<br> <TabAtkins> futhark: We don't implement the "of <selector>" at all in Chrome yet<br> <fantasai> TabAtkins: Right now everyone supports :th-child(), only safari supports :nth-child-(.. of selector)<br> <fantasai> TabAtkins: we have a resolution the books to restrict that selector to compound selectors<br> <fantasai> TabAtkins: we're reversing that resolution<br> <TabAtkins> chrishtr: So that won't have any effect on chromium and gecko shipping :has(), and forward compatible with us shiping the upgraded :nth-child() in the future<br> <TabAtkins> TabAtkins: yeah<br> <TabAtkins> chrishtr: So this is kinda just a technicality?<br> <TabAtkins> astearns: Yeah just level wrangling<br> <TabAtkins> astearns: Either we get a second impl of this in :nth-child(), or we get really close with everything else in level 4 and we defer *all* of the :nth-child() enhancements to advacne the spec<br> <TabAtkins> emilio: Or we get a second impl but that only did simple selectors, we could punt the complex selectors again. But doesn't matter much for impls right now.<br> <TabAtkins> chrishtr: Sounds fine, doesn't affect our current impl plans.<br> <TabAtkins> astearns: So, any objections?<br> <TabAtkins> RESOLVED: Revert the resolution from #3760, removing the "no complex selectors" restriction from :nth-child()<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/3760#issuecomment-1143866079 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 1 June 2022 16:47:49 UTC