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

The CSS Working Group just discussed ``[selectors][css-scoping] Should `:host:has()` match?``, and agreed to the following:

* `RESOLVED: :host:has() can match, :has() can't`

<details><summary>The full IRC log of that discussion</summary>
&lt;TabAtkins> :host:has(.foo)<br>
&lt;keithamus> TabAtkins: someone added tests in WPT combining :host:has. Some test well specified behaviour, but they added some tentative about using :host:has next to eachother in a compound selector<br>
&lt;keithamus> ... tentatively wrote assuming this works and it matches the host element assuming a .foo is in the tree<br>
&lt;keithamus> ... that doesn't work because :has doesn't match featureless elements in general<br>
&lt;keithamus> ... the :has pseudo class should be able to match the host. Again, :host is featureless because authors of the shadow tree cannot predict the markup so it would have to be written defensively<br>
&lt;emilio> q+<br>
&lt;keithamus> ... the :has pseudo class only matches based on descendents, ie stuff in the shadow tree thus already in control of the author<br>
&lt;keithamus> ... so predictable behavior and no defensive coding<br>
&lt;keithamus> ... there's also some examples this satisfies in the thread<br>
&lt;TabAtkins> :host:has(.foo) and :has(.foo) both are allowed to match<br>
&lt;keithamus> ... so :has should be added to the list of things to match the host element<br>
&lt;keithamus> ... also unqualified :has(.foo) should be able to match the host element<br>
&lt;keithamus> ... This is potentially confusing because no selectors currently match :host... nothing else can do this right now so it might not be expected.<br>
&lt;keithamus> ... The benefit of allowing is that matching behavior becomes much more sensible if it is allowed to match unreservedly<br>
&lt;emilio> Feels wrong that `*:has(..)` and `:has(..)` behaves differently<br>
&lt;keithamus> ... it makes speccing more complex if not<br>
&lt;keithamus> ... the simpler model, I think, is a little better<br>
&lt;astearns> ack emilio<br>
&lt;TabAtkins> *:is(:host) and :is(:host) already match different<br>
&lt;keithamus> emilio: I get the use case of matching inside the shadow tree, I'm not sure I agree with making it match when not qualified. It feels wrong that * doesnt match but unqualified does.<br>
&lt;keithamus> ... I guess you're right that's already the case per spec<br>
&lt;keithamus> ... something matching host that doesnt contain :host feels bad<br>
&lt;keithamus> ... I find it confusing. Especially as styles go outside your component<br>
&lt;keithamus> ... either force :host or do a new pseudo or something<br>
&lt;astearns> q+<br>
&lt;keithamus> ... I think I have a preference for enforcing :host especially as it doesn't change the behaviour for unqualified selectors<br>
&lt;keithamus> TabAtkins: I suspect that unqualified :has is rare to non-existent as it could potentially match all elements. I would be surprised if it causes problems<br>
&lt;keithamus> ... open to possibility that it would though<br>
&lt;astearns> ack astearns<br>
&lt;keithamus> astearns: I didn't go into the use cases but are the use cases presented for unqualified has that cannot be done with qualified has? Or is it ergonomics<br>
&lt;keithamus> TabAtkins: purely ergonomics, purely a matter of ergonomics/spec complexity to make it work one way or another<br>
&lt;keithamus> emilio: implementation complexity implies there is a benefit, then you can avoid looking at those selectors altogether<br>
&lt;keithamus> TabAtkins: but you would still know which selectors are potentially able to match<br>
&lt;keithamus> ... this expands the set of potential matches from things to the :host to things with unqualified :has<br>
&lt;keithamus> emilio: :is also complicates, but if you have :host in the subject it can only match the host. :has can match random stuff in the tree<br>
&lt;keithamus> emilio: I think unqualified :has matching :host is not great as an author<br>
&lt;keithamus> ... other than my gut feeling I dont have strong arguments one way or another<br>
&lt;keithamus> TabAtkins: are you implying theres a benefit to saying these selectors only apply to host or not? Being able to match either host or shadow tree is more complex?<br>
&lt;keithamus> emilio: yeah. We can put the selector in a separate place to style the element, otherwise it's in the general place<br>
&lt;keithamus> TabAtkins: the spec side, it means adding another clause to the conditions for what allows a compound selector to match a host element<br>
&lt;keithamus> ... not a huge complexity but one more thing in the list<br>
&lt;keithamus> emilio: spec or implementation complexity aside, I wonder what other authors think? A bare :has with random stuff inside accidentally matching the :host?<br>
&lt;keithamus> astearns: the person who wrote the tests is not thinking about this accidentally perhaps<br>
&lt;keithamus> ... I'd like to see what the valid use case is. Speaking personally, I think I'd like the use cases to justify this<br>
&lt;keithamus> TabAtkins: for the feature entirely? Or needing :host to be spelled out?<br>
&lt;keithamus> astearns: allowing a selector that doesn't explicitly use :host to match the host<br>
&lt;keithamus> emilio: you claim the test author mentioned that? As far as I can tell they don't test that<br>
&lt;keithamus> TabAtkins: all tests have :host:has. In the mindset of testing that :host matches appropriately.<br>
&lt;keithamus> TabAtkins: I'm fine with resolving with emilio's ammendment<br>
&lt;TabAtkins> :host:has() can match, :has() can't<br>
&lt;keithamus> PROPOSED RESOLUTION: :host:has() can match, :has() can't<br>
&lt;oriol> q+<br>
&lt;keithamus> oriol: I think this breaks the assumption from the previous issue<br>
&lt;keithamus> ... when we have compound selector allowed to match host, here has wouldnt be allowed but the combination would<br>
&lt;keithamus> ... so it breaks the general rule?<br>
&lt;keithamus> TabAtkins: changing that rule to special case this would be part of that resolution<br>
&lt;keithamus> oriol: so what would the general rule be?<br>
&lt;keithamus> TabAtkins: I'll show the spec<br>
&lt;keithamus> RESOLVED: :host:has() can match, :has() can't<br>
</details>


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


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

Received on Wednesday, 14 August 2024 17:04:27 UTC