[css-selectors] has-child selector

[chrishtr]

Proposal: add a selector that matches an element if a direct child matches the selector in the function.

"all a elements that contain an img" -> a:has-child(img)

Motivation: #2 missing-features request in the state-of-CSS 2019 survey.

Since it only matches direct children, it may be no more expensive than sibling selectors.

A related selector that was considered and removed as too expensive and slow (AIUI) is :has. See also resolution regarding it here.

@tabatkins @lilles

[andruud]

Hopefully most of the respondents actually did mean parent (:has-child) and not ancestor (:has-descendant).

@argyleink @una Do you have any gut feeling regarding this? The survey says "parent selector", which we're interpreting as "immediate parent selector", whereas I'm worried some respondents actually want "ancestor selector" (which would be way more expensive).

[lilles]

Regarding performance cost, it's more similar to indirect adjacent or :nth-* selectors than direct sibling selectors. In Blink, invalidation sounds straightforward, quite similar to how we invalidate for the previously mentioned selectors.

:nth-selectors are typically implemented with a cache (at least Blink and Gecko/Servo) to avoid repeated O(n) traversals for multiple siblings. :has-child() would only be done once for a set of siblings, since they can only have a single parent, but if you have multiple :has-child() selectors matching the same element, we would possibly want to avoid multiple passes over the children somehow for :has-child().

The current spec text for :has() does not limit this to the rightmost compound. It's not obvious to me that: "div a:has-child(img) span {}" does not have more performance implications than only allowing :has-child() in the rightmost compound.

[emilio]

Hmm, I don't think invalidation sounds so straight-forward? Now dom mutations can invalidate styles of ancestors, which as far as I know all engines (including Blink) assume cannot happen.

Sure, it's only one-level ancestor, but it is not if you nest them, right? So div:has-child(div:has-child(img)) or such.

[emilio]

And at that point you may as well just implement full :has support?

[lilles]

Yes, div:has-child(div:has-child(img)) is essentially a different syntax for a variant of :has, so my assumption would be that :has-child() only takes a compound or compound list, not allowing nested has-child() or any other simple selectors which can contain combinators sigh, and as previously mentioned only in the rightmost compound.

In Blink, the invalidation for nth-* selectors is similar to what we would do here. Mark an element if it either matched or failed to match a :has-child() selector, and when any of its children mutates and the flag is set, mark that parent for style recalc.

[bkardell]

Just want to agree with @andruud here that I am a little unconvinced that these are not confused in the poll and overlapping. I asked this back in Feb, connected by them via twitter on just how it was even worded? but didn't get any reply. In most of my conversations, by parent selector, many people seem to have different interpretations

• some think this means < instead of just `>' which is just "change the direction of matching" and... that's kind of more than even has because you could switch all over.
• some thinks this means some variant of a :has proposal (any ancestor)
• some thinks it means literally parent, but don't think it has any limits

I'm just one person tho, and understand that's all anecdotal.

It's also not to say that something very limited has no use... It feels worth a nice post explaining a proposal and its limits and getting feedback from devs though first?

[chrishtr]

@bkardell I agree that we don't have enough data to say whether parent means parent or ancestor, or similar potential abiguities.

A post explaining and gathering feedback would be excellent. Were you volunteering to help with that? Would be great if so, just checking.

[tabatkins]

Sure, it's only one-level ancestor, but it is not if you nest them, right? So div:has-child(div:has-child(img)) or such.

In previous discussions of this (largely predating us using GH, unfortunately), it was presumed that nesting :has-child() would be invalid.

So you could have :has-child() at multiple points in a selector, like div:has-child(img) + label:has-child(:checked), but you wouldn't ever be able to recurse with it.

I assume we'd definitely impose this restriction, else this is just a less convenient way of writing :has(), as you say.

[lilles]

Thinking about it again, limiting this to rightmost compound would not be a requirement. Tab's "div:has-child(img) + label:has-child(:checked)" example, or "div:has-child(img) span" should also have similar performance implications.

[argyleink]

Hopefully most of the respondents actually did mean parent (:has-child) and not ancestor (:has-descendant).
@argyleink @una Do you have any gut feeling regarding this?

From my experience folks exclusively mean ancestor querying. Eg, they want a child to own how it responds to a class or state findable further up the DOM. @bkardell had it right when using the < character, as a way of visualizing the intent .dark < .my-component {...}. I dont know anyone who's aware of :has when talking about this topic.

[bkardell]

@chrishtr
I would be very happy to do that, yes, if we can agree to some concrete proposal(s) to offer and explain that also describe the relatively likeliness of implement-ability. It's probably one of those things that even if it is a kind of unofficial poll though should probably have some review to make sure it doesn't create a similar confusion indirectly somehow so maybe if another person or two would offer to work on it together, that would be most helpful.

[SebastianZ]

The :has-child() selector is effectively a sub-feature of :has() and it sounds like allowing arbitrarily deep selectors may not be implementable in a performant way.

So another approach to this would be to restrict :has() to a simple relative selector, i.e. <combinator> <simple-selector>. This avoids introducing two functional overlapping pseudo-classes, already covers many use cases, and is more performant than allowing complex selectors.

And if that resolves the performance issues regarding :has(), it hopefully gains some traction by implementors and doesn't require the note that "Supporting the :has() pseudo-class is not required to conform to this specification.".

In a later level, :has() may then still be enhanced to allow complex selectors to cover the rest of the use cases, but in the meantime, authors already get something they can work with.

Sebastian

[faceless2]

PrinceXML has already implemented :has() as currently specified and is shipping, and we have too (but are't shiipping yet).