Re: [csswg-drafts] [selectors][css-scoping] Should `:host:has()` match? (#10693)

I think there are a few cases here that it would be great to untangle and specify.

### **Background**

The spec defines [Tree-Structural pseudo-classes](https://drafts.csswg.org/selectors/#structural-pseudos), but it doesn't specifically distinguish the scope or relationship: ancestor or descendent. 

Similarly, [:host()](https://drafts.csswg.org/css-scoping-1/#host-selector) matches the argument in the host's "normal context," the scope in which the host itself exists, not its Shadow DOM.

Additionally, there's a special carve out for the [flat tree](https://drafts.csswg.org/css-scoping-1/#flattening) against which match `:hover`, `:active`, `:target-within`, and `:focus-within`. And the syntax uses the function version:`:host(:focus-within)`.

Currently, `:host(:empty)` works and matches against the host's light tree. As noted, `:host(:has(...))` seems like it should work, but it's currently not well supported.

### Discussion

When Shadow DOM is involved, for the cases defined in the spec, only a descendent relationship is relevant to consider since this could be either via the light or shadow tree or both, the composed tree.

The example noted [above](https://github.com/w3c/csswg-drafts/issues/10693#issuecomment-2275737823) `:host:nth-child(…)` needs no consideration since its based on an ancestor relationship (host within parent). It should never be able to match.

I believe only `:has(...)` and `:empty` are potentially ambiguous since they could match against the light, shadow, or flat tree. 

Using the functional `:host(...)` syntax, it does seem like the spec is suggesting these should match agsinst the light tree, and they do (minus bugs).

Matching these against the shadow tree does seem useful as is suggested here, and using the non-functional syntax also seems to make sense `:host:has(...)` or `:host:empty` (seems like this should also work).

### Caveats
Adding the capability makes sense, but I see 2 downsides to using this syntax for it:
1. It's unclear if there's a mental model for when to use the functional syntax `:host()` and doing to changes the meaning. For example, why is it `:host:after` and not `:host(:after)`? At least only one of those works.
2. Using light v. shadow tree as a key for when to use the functional v. non syntax would break down for flat tree matching selectors like `:host(:focus-within)`.

-- 
GitHub Notification of comment by sorvell
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10693#issuecomment-2276277329 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Thursday, 8 August 2024 17:01:54 UTC