[selectors-4] Add :has() to the list of logical combination pseudo-classes

[kbabbitt]

As discussed in #10693.

[cdoublev]

I think pseudo-elements cannot be followed by :has().

This specification allows any pseudo-element to be followed by any combination of the logical combination pseudo-classes and the user action pseudo-classes.

There is probably a good reason for :has() to be in the "Logical Combinations" section but I see it as a tree-structural pseudo-class.

[kbabbitt]

I think pseudo-elements cannot be followed by :has().

This specification allows any pseudo-element to be followed by any combination of the logical combination pseudo-classes and the user action pseudo-classes.

Good point, this is an unintended consequence of the proposed edit I hadn't realized. ::first-line:has(...) seems like a reasonable thing to express but could lead to dependency cycles so I don't think we want to allow it. And I don't see how ::before, ::after, or ::first-letter could possibly match :has(), so there's no reason to allow those either.

There is probably a good reason for :has() to be in the "Logical Combinations" section but I see it as a tree-structural pseudo-class.

I can see both sides of this. On one hand, because :has() takes a <relative-selector-list> there's an implied OR between the selectors in that list. On the other hand, unlike :is(), :where() and :not(), :has() requires examining the tree beyond the subject of the selector. @tabatkins / @fantasai wdyt?

[tabatkins]

It's not really a logical combination pseudo, which is why we didn't include it in that list in the first place. Logical combination pseudos don't do anything at all, theoretically, that you couldn't achieve by just writing out the selectors manually. (Well, :not() is a new ability, but it's such a clear mirror to what its argument can do that it's morally not new.) So allowing them, with the caveat that you can only use arguments that could already show up there by themselves, doesn't raise any questions.

:has() is totally new functionality, and can't be treated as cavalierly. Editing for #10693 needs to be a bit more fiddly, unfortunately.