[css-shadow-parts] need definition of which pseudo-classes can follow `::part()` that is sufficient to produce interoperability

[dbaron]

The spec for ::part() says:

The ::part() pseudo-element can take additional pseudo-classes after it, such as x-button::part(label):hover, but never matches the structural pseudo-classes or any other pseudo-classes that match based on tree information rather than local element information.

This wording probably isn't precise enough to lead all implementors to classify every pseudo-class (works after ::part() or not) in the same way. I just added a test to WPT that exercises a bunch of these cases. (See also #10786 for a separate issue that relates to the same test. And also see #9795 for a case where people previously disagreed about this classification.)

We probably need a clearer definition of which selectors do or don't work here, and it probably needs to somehow end up in the way that we define pseudo-classes.

[dbaron]

Perhaps a special case: I think it should probably be clear that :has() isn't allowed; it's probably not testable today but it could be in the future if we introduce something equivalent to what was allowed in early :has() drafts by :has(:scope:hover) (which is roughly equivalent to :is(:hover)).

[tabatkins]

Agreed.

I think the definitely-disallowed ones are:

• the structural pseudo-classes, as already disallowed
• :has()
• :scope
• :host, :host(), and :host-context()

Slightly uncertain ones that I think should still be allowed:

• :lang() and :dir() (we already resolved to allow them)
• the :*-within pseudos (:target-within, :focus-within
• :picture-in-picture

And I think the rest are all clearly fine.

I made this list by looking over https://drafts.csswg.org/indexes/#selectors which gets selectors from across the spec landscape, so should be pretty complete (anything it's missing are just mis-tagged).

[dbaron]

I think also probably disallowed (as structural) should be :scope, :host-context() and :host.

[tabatkins]

I'd considered them, but left them out as I figured they could never match. But you're right, for clarity they should be disallowed explicitly.