[selectors-4] Consider disallowing logical combination pseudo-classes inside :has()

[anttijk]

That is disallow nested :has()

:has(:has(foo))

and

:has(:not(foo))
:has(:is(foo))
:has(:where(foo))

These cases complicate style invalidation in the engine too much while also being difficult to reason about and generally not very useful.

It is also easy to make mistakes with :has(:not(foo)) since it may be non-obvious it is not the same as :not(:has(foo)).

[Loirooriol]

I disagree with "generally not very useful":

• :has() + :not(): something like :has(#foo:not(.bar)) seems very useful to me.
• :has() + :is(): useful for complex selectors, e.g. .foo:has(.bar .baz) requires .bar to be a descendant of .foo, but .foo:has(:is(.bar .baz)) doesn't. Sure, I could rewrite it as

  .foo:has(.bar .baz), .foo.bar:has(.baz), .bar .foo:has(.baz)

  but in more complex cases the combinatorial explosion of cases can be cumbersome.
• :has() + :where(): same

:has() + :has() could have its uses but yeah, generally it seems less useful.

[jensimmons]

I'd like to provide some context for those web developers commenting or reacting that they don't like this idea and would prefer every possible combination of selector syntax be allowed.

The reason browsers did not implement a parent selector many years ago is because there are some pretty alarming performance concerns. It could have been very easy to choke a browser from the 2000s, making a web page slow to an unusable state. In fact, even in the first half of 2021, we were still not sure it was possible to implement :has(). Folks at Igalia and Apple worked hard to figure out how to make :has() possible at all, given performance considerations. We shipped an early version in Safari Technology Preview, so we could identify & fix bugs and further test performance.

Everyone would love to implement :has() with no limitations. But that may be impossible. We have to make sure this new CSS selector doesn't give web developers a way to trash the performance of their website.

This issue is for the CSSWG to discuss, as we figure out a way to create a selector that does what most developers need most of the time, without any bad consequences.

Please don't give us a hard time about it. What we wish for and what we need to do because of reality don't always perfectly match. And it is looking terrific for an incredibly useful selector finally becoming reality, after years of pent up desire.

[SelenIT]

I’d be fine with these limitations for :has() in L4 if it helps all browsers implement it sooner. It’s still infinitely better than restricting it to scripting only, as it was proposed earlier. To me, even limiting the argument to one combinator plus one compound selector (instead of arbitrary complex selectors) would be way better than nothing for many practical cases, and if it would allow to get rid of the “optional” status of :has() in the spec, I would accept that trade-off. Further extensions and improvements of this selector could be deferred to L5.

[SelenIT]

One of use cases for :not() inside :has() seems to be telling apart elements containing text from those that contain only other elements (e.g. see this Twitter tread). There would be no need to employ this combination for this task if there would be a dedicated selector for elements with text, e.g. :has-text. Are there any plans to introduce something like this?

[Loirooriol]

To be clear, while I disagreed with these combinations not being useful, I'd fine with the limitations, for the reasons stated above.

But, regarding :not(), I wonder if it could be allowed in its basic L3 form: :not(<simple-selector>), excluding nesting.

[SelenIT]

I guess it's more important to get :has() implemented in browsers sooner, the way it possibly can be implemented. If some reasonable limitation can help it while still allowing to check for dynamic pseudo-classes and DOM modifications inside :has(), let it be so. Something would be better than nothing (and yes, limiting :has() to scripting only was virtually equal to nothing from CSS engineers perspective).

It's another question whether invalidating :not() inside :has() would be that much more complicated than, e.g. invalidating :nth-last-child() (and the latter case would be definitely useful, the ability to switch the container from block to grid and back depending on the number of items is what developers often ask for). But implementers surely know better, let's listen to them!

Also, I guess the question relates basically to all functional pseudo-classes accepting selector lists, so, if the limitation is needed, :nth-child(... of S) inside :has() would be disallowed as well?

[anttijk]

The nested case :has(:has(foo)) is now disallowed in WebKit but the other logical combination pseudo-classes are still allowed. The performance of using those is not optimal but we can probably live with that for now.

I think the nested case should be disallowed by the spec. No one seems to have came up with any real uses for that.

[tabatkins]

I'm fine with disallowing nesting. We've done similar in other non-selector cases to limit complexity. There are definitely use-cases for it, but they're indeed minimal.

If at all possible I'd like to avoid disallowing the other selectors, even if the perf isn't ideal. We have much better tools these days to expose and analyze selector performance than we did a decade ago.

I presume this means that nested :has() is disallowed even when "shielded" by another selector, like :has(:not(:has(.foo))), right?

[SelenIT]

Since :has() has proven to be implementable and this one limitation helps keep its performance at least acceptable for most practical cases, maybe it's time to remove its "optional" status and "at risk" mark as well?

[anttijk]

Correct. Any nesting, direct or indirect, is disallowed.