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

[jonesiscoding]

Selectors Level 4

This is a request to add pseudo-class selectors (:valid-within & :invalid-within) that would apply to any element that contains an element which matches the conditions used for the :valid or :invalid pseudo-classes.

The use cases would be very similar to those of the :focus-within pseudo-class. The most obvious case would be if one wanted to style a containing parent element of an input with a different background color, such as in the attached example.

I know that it is already possible to style siblings that follow the input via input:invalid <+/~> <selector> (as long as one can control their source order), however the proposed pseudo-class would have a wider range of uses and not require specific source ordering.

These selectors were mentioned briefly as a comment in #457, pertaining to :target-within. I could not find other discussions of the same.

[css-meeting-bot]

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

The full IRC log of that discussion

<dael> Topic: :valid-within / :invalid-within pseudo-classes
<dael> github: https://github.com//issues/3072
<dael> fantasai: Proposal to add valid-within and invalid-within pseudo classes. Seemed reasonable. Want to know if WG thought we should add
<dael> astearns: Anyone with a ready opinion?
<dael> fantasai: not urgent
<dael> astearns: Let's take this as a call for review and add comments in github
<dael> emilio: I can add comment to issue. Alternative is you have a pseudo class on the form and not just any arbitrary ancestor
<emilio> s/emilio/heycam
<dael> fantasai: I think that's what we do, but I'll check. If it's not we can make it work on form
<dael> fantasai: I think that would solve the use case. If it works on forms and fieldsets maybe.
<dael> fantasai: Looks like they're using at a smaller level for a segment of a form. Don't know if that solves the use case.
<dael> fantasai: We can continue that conversation in issue
<dael> astearns: Thanks for bringing it to attention. Please comment on the issue and we can see if we should take or modify this

[heycam]

Looking at the example now, having these pseudo-classes only apply to <form> wouldn't help here. And I can see that it would be useful to do something like apply it to the <tr> that contains the invalid form control.

[emilio]

My only concern would be performance, but I guess we already do kind of the same for focus changes with :focus-within, so probably not as much of a concern until proven otherwise?

[upsuper]

The current implementation of :focus-within in Gecko is by setting an independent bit flag on element, and apparently we have limited available bit flags without bloating every element in every page, so that pattern is not really scalable in terms of performance...

[AmeliaBR]

The validity pseudoselectors are already spec'd to apply to <fieldset>, which can be used as a generic grouping element within a form. That seems to be supported everywhere that supports the selectors on <form> (confirmed in Firefox & Chrome). (Codepen test case)

Beyond that, I'd much rather see the generic :has() selector get adopted rather than an ever-growing set of :something-within selectors.

[SelenIT]

Unfortunately, Edge 17 still doesn't support :valid/:invalid for neither <fieldset> nor <form> :( The corresponding bug has been open since 2016.

Regarding the :has() selector, I'm rather skeptical about its future because limiting it to the "snapshot profile" would probably make it too much pain for too little gain for implementers. In JS, there are already (almost) equivalent ways to do its job, including one-liners like [...document.querySelectorAll('.part-before-has')].filter(el=>el.querySelector('.part-inside-has')), and browser vendors unlikely would invest much effort in adding more complexity to CSS parser engine etc. just to add just one more way to do the same (even slightly more elegant one). Personally, I would prefer introducing subsets of :has() that can be reasonably implemented in "live profile" (like :has-children() and :has-following-siblings() mentioned by @tabatkins in #1694)... and even probably dropping the "snapshot profile" concept at all (as kind of a premature optimization:).

[css-meeting-bot]

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

The full IRC log of that discussion

<dael> Topic: :valid-within / :invalid-within pseudo-classes
<dael> github: https://github.com//issues/3072
<bkardell_> q+
<dael> astearns: Anything anyone knows we can resolve on? WE were discussing in issue
<dael> fantasai: Flag this for selectors 5? Don't see anything
<dael> bkardell_: I think I would support Selectors 5.
<astearns> ack bkardell_
<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?
<dael> bkardell_: Other requests for empty/blank within. Just ways of scooting around can't do :has
<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
<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
<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
<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
<bradk> :has(:focus|:target|:focus-visible|:valid|:invalid)
<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
<fantasai> bradk++
<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
<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.
<dael> emilio: Slight difference between within selectors and has. within work on flat tree and can cross shadow bounderies. Worth considering.
<dael> TabAtkins: Forgot about that. That is interesting
<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
<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.

[kizu]

I would totally welcome a non-chaining :has-child(). Of course, there are much more use cases for the :has(), but if :has() wouldn't be ever done due to performance constraints, then just a :has-child(), even non-chaining, would be such a powerful tool. Of course, you won't still have everything, and would need to think a bit more about HTML structure, but I'd say that most cases for :has() could be solved via :has-child(), and allowing developers to use this kind of thing would be very big.

If the fear of “not powerful enough, not covers enough use cases” would deny this compromise, no one would win from it.