Re: [csswg-drafts] [selectors-4] :valid-within / :invalid-within pseudo-classes

The CSS Working Group just discussed `:valid-within / :invalid-within pseudo-classes`.

<details><summary>The full IRC log of that discussion</summary>
&lt;dael> Topic: :valid-within / :invalid-within pseudo-classes<br>
&lt;dael> github: https://github.com/w3c/csswg-drafts/issues/3072<br>
&lt;bkardell_> q+<br>
&lt;dael> astearns: Anything anyone knows we can resolve on? WE were discussing in issue<br>
&lt;dael> fantasai: Flag this for selectors 5? Don't see anything<br>
&lt;dael> bkardell_: I think I would support Selectors 5.<br>
&lt;astearns> ack bkardell_<br>
&lt;dael> bkardell_: I know raised on issue, but how far do we want to care within thing? We have target-within and focus-within, but that was before focus-visible so now we need focus-visible-within. Also ask for valid-within, invalid-within. Valid use cases, but why just those?<br>
&lt;dael> bkardell_: Other requests for empty/blank within. Just ways of scooting around can't do :has<br>
&lt;dael> TabAtkins: Reason we have a small list is we can't do has because it's dramatically expensive. Can do a small number of carefully controlled state-based, everything we add is substantial additional cost. There will always be a small list of what we allow. Larger list of what we want, but can't do all. Everything has a good argument, but need to be selective on what include<br>
&lt;dael> bkardell_: Suggesting see if create something reasonable that avoids some of that. Maybe impossible or unlikely that we'll have has. I don't know that there's not something we can do that's acceptable and not prone to a lot of withins and explaining why some are and some aren't. Something clearly articulates<br>
&lt;dael> TabAtkins: There is no clear articulation. It's the most high value and worth spending impl and perf penalties. It's arbitrary. No clear reason for cut off. It's we don't feel we should add more. What's left isn't woth increasing<br>
&lt;dael> TabAtkins: Boris has argued a simple has-child might be something impl are amenable too. It's a simple case of how much you need to check. has-child is only up one level, more limited in cost. Might be okay for cost. Will cover a lot of what people need. Won't be everything and can't allow chaining. If we feel a lot of use cases can be addressed by parent caring about children that's a direction - we should check use cases<br>
&lt;bradk> :has(:focus|:target|:focus-visible|:valid|:invalid)<br>
&lt;dael> bkardell_: That's what I mean. I know Boris had interesting ideas. I've had similar convos with number of impl. A lot of thoughts as what we could do. Instead of doing lots of withins let's see what we can do to take a big chunk of stull<br>
&lt;fantasai> bradk++<br>
&lt;dael> TabAtkins: Might be good to look at lots of cases to see if it's just parent/child or more. If it's mostly parent/child it's worth looking at has-child. That's a study that should be done. I recommend if you're interested in pursuing this<br>
&lt;majidvp> fantasai: no new update. I have not had a chance to work on this since last update. My next step was to look at the mobile data from httparchive. Pending that does not raise a red flag we can try to fix this in Blink.<br>
&lt;dael> emilio: Slight difference between within selectors and has. within work on flat tree and can cross shadow bounderies. Worth considering.<br>
&lt;dael> TabAtkins: Forgot about that. That is interesting<br>
&lt;bkardell_> that is also part of what I mean, that is maybe worth articulating as a criteria we use for determining whether we'd consider a thing and why<br>
&lt;dael> astearns: All this will go into issue. Sounds like we should continue there and look at figuring out if this goes into selectors 5.<br>
</details>


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

Received on Wednesday, 14 November 2018 17:49:29 UTC