[selectors] Drop `:target-within`, deprecate `:focus-within`

[LeaVerou]

:target-within and :focus-within were added to the language during an era when we thought we could never do :has(). They are special cases of :has(), namely to :has(:target) and :has(:focus). Now that we have :has(), there's no reason to have them in the language. :target-within has no implementation, so we could just drop it. :focus-within is widely used (~8% of websites) but it may make sense to deprecate so we could drop it one day, if usage drops.

[Loirooriol]

Just pointing out that

• :focus-within includes the element itself, so it may be convenient to avoid :is(:focus, :has(:focus))
• :focus-within includes descendants in the flat tree, unlike :has(:focus)
• It's likely that :focus-within has better performance

[LeaVerou]

:focus-within includes descendants in the flat tree, unlike :has(:focus)

Oh that's a very good point.

[fantasai]

@LeaVerou do you still want to pursue this, or is @Loirooriol's response good enough to retract it?

[LeaVerou]

@LeaVerou do you still want to pursue this, or is @Loirooriol's response good enough to retract it?

There's still the part about :target-within.

[dbaron]

I think the other value of these selectors is that they are much faster than :has() (though they require the browser to do a little bit of extra up-front work to get that benefit). I'm still quite concerned that :has() is going to create selector performance problems that will require things like lints to forbid :has() and developers to know to avoid it.

While in theory we could detect and optimize some very specific cases of :has() such as :has(:target), that seems like it would create more confusion around what the performance characteristics of CSS selectors are. There's value in creating a platform that is understandable to the developers that use it -- and this does apply to its performance characteristics.

[LeaVerou]

While in theory we could detect and optimize some very specific cases of :has() such as :has(:target), that seems like it would create more confusion around what the performance characteristics of CSS selectors are. There's value in creating a platform that is understandable to the developers that use it -- and this does apply to its performance characteristics.

There is definitely value in creating a platform that is understandable to the developers that use it; however my understanding was that one of the core design principles of CSS these days is that authors should not need to worry about performance at all; if something cannot be implemented performantly, it's not implemented at all. Is this not the case with :has()? I thought the whole reason :has() became feasible was that it was shown it could be implemented with reasonable performance. Is this not the case?

[dbaron]

I believe the performance of :has() is significant in some cases, although that belief is based on conversations with implementers rather than measurement. In particular, I see occasional suggestions for things like implementing a dark theme checkbox using :root:has(#dark-theme-control:checked) ... selectors, and my understanding is that a significant number of :root:has(...) selectors on a large page would add up to a measurable performance problem.

[LeaVerou]

I suspect once such usage of :has() becomes more widespread, there will be further optimizations for common patterns. We should not be designing CSS syntax around transient performance issues. Especially since such messaging takes a very long time to go away — there are devs even today who hesitate to use descendant selectors because of 2010 era guidance around selector performance.

[bkardell]

Just want to add more than a thumbs up here and re-state that I don't think we should deprecate :focus-within for all of the same reasons @Loirooriol mentioned above. It means something different than any :has() and also, (but not the main reason) because it is very specifically about focus it can also be very efficient at that.

[css-meeting-bot]

The CSS Working Group just discussed Dropping :target-within, deprecating :focus-within, and agreed to the following:

• RESOLVED: Keep :focus-within, replace :target-within with a note that we hope :has(:target) is sufficient for use cases

The full IRC log of that discussion

<fantasai> Topic: Dropping :target-within, deprecating :focus-within
<fantasai> github: https://github.com//issues/8357
<fantasai> TabAtkins: It's possible we can just close this?
<fantasai> TabAtkins: Oriol points out that :focus-within has a number of arguments in favor of existence
<fantasai> TabAtkins: it operates on flat tree, has better perf, and includes the element itself
<fantasai> TabAtkins: Lea agrees
<fantasai> TabAtkins: :target-within, given no impl yet might be fine to drop, but I presume it has similar arguments for :focus-within
<florian> q+
<oriol> q+
<emilio> fantasai: In favor of keeping both for the reasons mentioned
<TabAtkins> fantasai: I'm in favor of keeping thm both for the reasons given
<fantasai> florian: I think we should definitely keep :focus-within, this has very relevant usage
<fantasai> florian: before we had :has() there was movement to add various :*-within for other things
<fantasai> florian: but now we do have :has(), so I'm less sure about adding more that are not as hot in terms of usage as :focus-within
<fantasai> florian: :target-within already in the spec, but no implementation, suggests lesser demand
<fantasai> florian: possibly to re-add later, if we observe :has()
<fantasai> florian: if too hard to optimize
<astearns> ack fantasai
<astearns> ack florian
<fantasai> florian: but if can do with :has(), seems fine
<astearns> ack oriol
<fantasai> florian: so I would keep :focus-within and drop :target-within
<fantasai> oriol: I agree we should keep :focus-within and drop :target-within
<fantasai> oriol: point about flat tree doesn't seem to apply, I couldn't get :target to work with shadow DOM
<fantasai> oriol: perf isn't an issue here
<astearns> ack fantasai
<Zakim> fantasai, you wanted to point out shadow tree aspect
<emilio> fantasai: wdym you can't make them work on the shadow dom?
<emilio> ... if you have anchors in your shadow tree, you can't make `:target-within` match that
<emilio> oriol: I'd need to test again
<emilio> q+
<fantasai> s/:target-within/:has(:target)/
<astearns> ack emilio
<fantasai> emilio: having :target match inside a shadow tree doesn't make sense, because URL only works in the outer tree
<fantasai> astearns: given lack of implementation, and implementation interest, I'd be OK adding a note saying that we believe :has(:target) is sufficient, but if there's some implication that requires it we might add it back
<fantasai> wfm
<fantasai> astearns: other opinions?
<fantasai> astearns: proposed resolution is to keep :focus-within and replace :target-within with a note that we hope :has(:target) is sufficient for use cases
<fantasai> RESOLVED: Keep :focus-within, replace :target-within with a note that we hope :has(:target) is sufficient for use cases