Re: [csswg-drafts] [selectors] Let :is() have better error-recovery behavior than normal Selectors (#3264)

The CSS Working Group just discussed `Error recovery for :is() and :not()`, and agreed to the following:

* `RESOLVED: Drop individual invalid selectors from selector lists in *all* selector functions that take such lists, *except* for :not().`

<details><summary>The full IRC log of that discussion</summary>
&lt;presenter> Topic: Error recovery for :is() and :not()<br>
&lt;astearns> github: https://github.com/w3c/csswg-drafts/issues/3264<br>
&lt;presenter> ewilligers: We resolved we'd like to have error-recovery for :is() and :where(), but unsure about :not().<br>
&lt;presenter> ewilligers: I have use-cases showing that :not() is used frequently, so we probably don't want to change the meaning.<br>
&lt;presenter> ewilligers: Do we want :nth-child() or :nth-last-child() have error-recovery?<br>
&lt;presenter> fantasai: nth-child should probably have the same error-recovery as :is()<br>
&lt;florian> fantasai: I think it would make more sense with compound, not complex selectors<br>
&lt;presenter> fantasai: The big question for nth-child was compound vs complex selectors.<br>
&lt;florian> fantasai: people want  that<br>
&lt;presenter> fantasai: If that makes it easier, would be good. Things like zebra-striping non-hidden rows.<br>
&lt;presenter> ewilligers: I think webkit already shipped complex selectors in nth-child<br>
&lt;fantasai> s/good/good to get it implemented faster/<br>
&lt;fantasai> s/rows/rows is a major use case that's not currently solved otherwise/<br>
&lt;presenter> dydz: I'm looking in the WK code<br>
&lt;presenter> fantasai: Emilio asked why we need selectors in :nth-child()<br>
&lt;presenter> fantasai: Say we have a list of items, I want to color their backgrounds alternating<br>
&lt;presenter> fantasai: But some of them are hidden; they're display:none<br>
&lt;presenter> fantasai: Counting is based on sibling list. If you hide 3rd one, 2nd and 4th will both have the same color<br>
&lt;presenter> fantasai: So want to count after filtering<br>
&lt;presenter> emilio: Whew, that's gonna be slow. We have a lot of caching already to make :nth-of-type() fast.<br>
&lt;presenter> ewilligers: I confirmed that Safari supports :nth-child(even of div+div)<br>
&lt;presenter> fantasai: My main concern is if other impls are more likely to implement without complex selectors, getting even compound-selector interop would still be great.<br>
&lt;presenter> emilio: I think impl-wise, not supporting complex selectors is easier.<br>
&lt;presenter> TabAtkins: Unless we recursively pass down the compound-only restriction into :is()/etc, you're at full power anyway.<br>
&lt;presenter> fantasai: Maybe that's reasonable to have that sort of restriction.<br>
&lt;tantek> agreed. reasonable restriction<br>
&lt;presenter> emilio: Did we decide on how the new error recovery behavior serializes.<br>
&lt;fantasai> fantasai: We'll just say Safari supports L5 of selectors, and L4 doesn't accept combinators<br>
&lt;presenter> emilio: Did we decide about serialization of invalid selectors in :is()?<br>
&lt;presenter> TabAtkins: I didn't think we were doing anything in particular?<br>
&lt;presenter> ewilligers: I thought we'd just drop them.<br>
&lt;presenter> emilio: What if they're all invalid?<br>
&lt;presenter> ewilligers: You just get :is(). A little weird with :nth-child(even of), tho.<br>
&lt;presenter> ewilligers: What about parsing of weird stuff? Extra close brackets, what happens?<br>
&lt;presenter> TabAtkins: Syntax already handles brackets correctly. We just split the tokens on top-level commas, then interpret each chunk as a selector.<br>
&lt;presenter> fantasai: So back to the issue: :is() and :not() take a list of selectors<br>
&lt;presenter> fantasai: Currently any invalid selector invalidates the entire selector list.<br>
&lt;presenter> fantasai: Because we now have these functional notations that creates some scoping, within :is() we can just ignore in the invalid selector, but still process the rest.<br>
&lt;presenter> fantasai: So we're gonna resolve that within :is(), we ignore invalid selectors.<br>
&lt;presenter> ewilligers: And :where(), :nth-child(), :has(), etc.<br>
&lt;presenter> fantasai: But not in :not() - the whole thing will invalidate if any are any invalid.<br>
&lt;presenter> gregwhitworth: I think it's weird to have :not() work different. I get the %s making it hard tho.<br>
&lt;presenter> AmeliaBR: I do use :not() as an @supports for new selectors...<br>
&lt;fantasai> AmeliaBR: e.g. :not(:valid) means you support :valid, and this selector selects things that are not valid<br>
&lt;presenter> TabAtkins: I was going over the boolean logic for :not() invalidating just parts too this morning, and was getting really confused...<br>
&lt;presenter> RESOLVED: Drop individual invalid selectors from selector lists in *all* selector functions that take such lists, *except* for :not().<br>
</details>


-- 
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/3264#issuecomment-467190906 using your GitHub account

Received on Monday, 25 February 2019 21:29:45 UTC