[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.

[romainmenke]

Can it be clarified if the outer or inner :has is invalid?

a:has(b, :has(> b)) c {
  color: red
}

Is the entire selector invalid in this case or only :has(> b) ?

If only the inner is invalid, this selector would essentially become :

a:has(b) c {
  color: red
}

[tabatkins]

I'd render the entire selector invalid.

[romainmenke]

I'd render the entire selector invalid.

I think that would be most clear for stylesheet authors.
A mistake would be noticed quicker.

[anttijk]

:has() uses forgiving parsing. Are there existing examples of a failure in forgiving parsing not being forgiven?

[tabatkins]

It's forgiving for the selectors inside of it, yeah, but the invalidity here is the outer :has(), since it contains a nested :has().

But I could be convinced otherwise, I suppose.

[romainmenke]

Not sure how much look ahead is needed and allowed, but that could be a factor?
If the inner is invalid it wouldn't require any.

[anttijk]

It is simpler to just make :has() invalid inside :has() and then follow the usual error handling rules, both in terms of logic and code.

[css-meeting-bot]

The CSS Working Group just discussed [selectors-4] Consider disallowing logical combination pseudo-classes inside :has(), and agreed to the following:

• RESOLVED: Disallow nesting :has() inside :has()

The full IRC log of that discussion

<fantasai> Topic: [selectors-4] Consider disallowing logical combination pseudo-classes inside :has()
<fantasai> github: https://github.com/w3c/csswg-drafts/issues/6952https://github.com//issues/6952
<fantasai> futhark: I think there is agreement to allow combinations like :is() and :where()
<fantasai> futhark: But implementors want to disallow :has() inside :has()
<fantasai> bkardell_: I think that's my impression as well. I think Safari implements this way as well
<fantasai> futhark: Implement in chrome and safari, but buggy
<fantasai> futhark: Don't think need to change the spec at this point
<fantasai> futhark: or to add any limitations, other than :has()
<fantasai> TabAtkins: I support this
<TabAtkins> github:
<TabAtkins> github: https://github.com//issues/6952
<fantasai> fantasai: proposed then that :has() cannot be nested inside :has()
<jensimmons> I've already found a useful usecase for figure:not(:has(:not(img))) { ... }
<fantasai> oriol: I think other combinations seem useful, but :has() inside :has() doesn't seem that useful
<fantasai> bkardell_: Originally wanted to disallow all of them, but based on feedback went back and made them work
<fantasai> bkardell_: said some perf implications, but seem livable-with
<fantasai> bkardell_: so let's just prohibit :has() inside :has()
<fantasai> astearns: Other opinions?
<fantasai> RESOLVED: Disallow nesting :has() inside :has()
<TabAtkins> I mean, I'm sure there are use-cases for nested :has(), but they're not as obvious and clearly worth the complexity cost, so I'm happy with this.

[romainmenke]

document.querySelector(":has(:has(body))");	
// vs. 
document.querySelector(":has(:has(body), body)");

In Safari (15.5) the first query throws with SyntaxError: The string did not match the expected pattern.
In Chrome (104) it returns null

The second query returns html in both browsers.

I am unsure which behaviour is correct, but I suspect this is a bug in Webkit if I compare with the behaviour of document.querySelector(":is(:invalid-thing)"); which returns null.

WPT also still lacks tests for error recovery in :has() : web-platform-tests/wpt#32200

[tabatkins]

Yes, that's a bug in Safari. The tests I just merged from you cover that case, tho. ^_^

[ByteEater-pl]

I wonder if scoping and nesting can emulate nested :has(). Specifically, how to rewrite A x B:has(C y D:has(E) F) z G, where capital letters are <relative-selector>s (single for now) and small letters are combinators. Reaching for a workaround would indicate that the author probably does know what it may imply for performance and is convinced it wouldn't hurt in his case.

Or is it impossible?