Re: [csswg-drafts] [selectors-4] Defer complex selectors inside :nth-child() etc. to L5 (#3760)

The CSS Working Group just discussed `Defer complex selectors inside :nth-child() etc. to L5`, and agreed to the following:

* `RESOLVED: Defer complex selectors for all of these selectors and have a note in the current level mentioning this is an enhancement we'll get to in the next level`

<details><summary>The full IRC log of that discussion</summary>
&lt;dael> Topic: Defer complex selectors inside :nth-child() etc. to L5<br>
&lt;dael> github: https://github.com/w3c/csswg-drafts/issues/3760<br>
&lt;astearns> fantasai: These selectors have been highly requested for years. We know that WK had impl the full functionality allowing combinators and everything but no one else has impl. There is a question of should we reduce scope of L4<br>
&lt;dael> fantasai: Question I wanted to ask is do we take this back to only allow compound for now and add complex in the future to make impl easier or is that not relevant concern?<br>
&lt;dael> fantasai: Interop of reduced subset solves most of the problems<br>
&lt;dael> AmeliaBR: No one would ask WK to rollback it's jsut defer to next level?<br>
&lt;dael> fantasai: Yes<br>
&lt;dael> astearns: Concerns from WK?<br>
&lt;dael> smfr: I think we're okay moving those bits to next level<br>
&lt;dael> astearns: IN issue question of how many selectors we defer complex selectors for.<br>
&lt;dael> astearns: Question is do we defer complex for :nth or also the is/where/not/has collection?<br>
&lt;dael> myles: For specs to get to rec we need two impl so why not start there?<br>
&lt;dael> astearns: With eerything?<br>
&lt;dael> myles: If not 2 impl and no plan for another one...<br>
&lt;dael> myles: We have to defer<br>
&lt;dael> myles: Sooner or later<br>
&lt;dael> fantasai: I don't want to have someone not impl and push off impl of these features in general because doing all at once is too much.If reducing size gets us an impl fast that's good.<br>
&lt;dael> fantasai: I want to hear from Gecko and Blink are you planning to impl and if yes would trimming make it faster<br>
&lt;dbaron> can you hear me?<br>
&lt;dael> TabAtkins: I have to ask, I'm not certain. WE're not against it but I don't know scheduling<br>
&lt;dbaron> stupid webex<br>
&lt;dael> AmeliaBR: Comment in issue from eric W that he started but hasn't worked recently<br>
&lt;dael> emilio: We don't have immediate plans to impl, but complex selectors really complicate getting invalidation right so it would definitely take more if we had to figure out combinators<br>
&lt;dbaron> So webex doesn't appear to be letting me rejoin, so I'll write my comment in IRC<br>
&lt;dael> fantasai: Is that true for the nths oly or also is/where/not<br>
&lt;dael> emilio: If we solve we have to do for all at once<br>
&lt;dbaron> oh, back in<br>
&lt;dael> fantasai: That seems like a good arguement to refer to next level if can get Gecko impl sooner<br>
&lt;dael> dbaron: I think if the result you want is finding out...is A encouraging impl and B finding out if extra parts will cause pain I think perhaps best way is add a note ot spec that says we're considering dropping. If they make your impl harder please impl without and let us know. Because then there's clear intent WG is interested in feature as a whole but also just those parts<br>
&lt;dael> fantasai: COuld do opposite and just add subset and note we're doing the rest in L5 and these already impl in WK but seemed too complex for others<br>
&lt;dael> florian: That's harder editorially. Do you think subset is easy to figure out in reading spec? Or is note saying can do subset is enough so don't have to editorially split it up<br>
&lt;dael> fantasai: If we're doing it for all at once it's quite simple editorially.<br>
&lt;dael> astearns: For myself it would be clearer reading spec to have complex selectors broken to next level with a note saying intend to add in future level. It's easy to look at production with complex selectors and miss the note and think it's too much<br>
&lt;dael> astearns: My preference is to defer complex selectors for all of these and have a note in the current level mentioning this is an enhancement we'll get to in the next level<br>
&lt;dael> astearns: Objections?<br>
&lt;dael> RESOLVED: Defer complex selectors for all of these selectors and have a note in the current level mentioning this is an enhancement we'll get to in the next level<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-477253690 using your GitHub account

Received on Wednesday, 27 March 2019 16:57:49 UTC