Re: [csswg-drafts] [selectors-4] Consider disallowing :host, :host(), :host-context() inside :has() (#7212)

The CSS Working Group just discussed `[selectors-4] Consider disallowing :host, :host(), :host-context() inside :has()`, and agreed to the following:

* `RESOLVED: No change`

<details><summary>The full IRC log of that discussion</summary>
&lt;fantasai> topic: [selectors-4] Consider disallowing :host, :host(), :host-context() inside :has()<br>
&lt;fantasai> github: https://github.com/w3c/csswg-drafts/issues/7212<br>
&lt;fantasai> futhark: Given resolution wrt :scope, at least from Chrome side, we agree that :host-context will neve match inside :has() because it needs to have sibling/parent ... shadow tree<br>
&lt;emilio> q+<br>
&lt;fantasai> futhark: not a perf problem, but it will never match<br>
&lt;fantasai> futhark: proposed resolution from our side is no change<br>
&lt;fantasai> TabAtkins: :host will never match as final selector, but the example here ...<br>
&lt;TabAtkins> .b:has(:host .a .c)<br>
&lt;fantasai> TabAtkins: slightly simplified version of a selector in the issue<br>
&lt;fantasai> TabAtkins: this would still match<br>
&lt;fantasai> TabAtkins: however it's exactly equivalent to just moving the :host outside<br>
&lt;fantasai> TabAtkins: if we were to ban it, wouldn't hurt anything, but is matchable in this instance<br>
&lt;fantasai> bkardell_: Because doesn't begin with a relative combinator<br>
&lt;fantasai> TabAtkins: so evaluates globally against the context<br>
&lt;emilio> q-<br>
&lt;fantasai> bkardell_: This is where the whole weird context comes from<br>
&lt;fantasai> bkardell_: I think a lot of ppl would not expect that to match<br>
&lt;fantasai> futhark: From impl side of things, it's not an important issue<br>
&lt;fantasai> futhark: removing special meaning of :scope means it's not a perf issue<br>
&lt;fantasai> bkardell_: so you would ... walk all the way up the tree?<br>
&lt;fantasai> bkardell_: Seems weird to me that this should match<br>
&lt;fantasai> bkardell_: basically nobody would expect it<br>
&lt;fantasai> TabAtkins: it's the same as putting :root in there<br>
&lt;fantasai> TabAtkins: why expect not to match?<br>
&lt;fantasai> bkardell_: Even in jquery etc., :has() you start matching at the boundary, you don't walk all the way up the tree<br>
&lt;miriam> q+<br>
&lt;fantasai> TabAtkins: Am I misremembering this?<br>
&lt;fantasai> :has(:is(:host .a)<br>
&lt;fantasai> )<br>
&lt;fantasai> maybe you mean something like that?<br>
&lt;miriam> q-<br>
&lt;TabAtkins> fantasai: The host element doesn't necessarily ahve to be inside...<br>
&lt;TabAtkins> fantasai: the host doen't have to be in the :has()<br>
&lt;TabAtkins> fantasai: When you have :is() tho, that doesn't necessarily get scoped.<br>
&lt;TabAtkins> fantasai: So if you nest it like this, this could match.<br>
&lt;fantasai> :has(:is(:root .a)) would match, for example<br>
&lt;fantasai> TabAtkins: That's right, would do it<br>
&lt;fantasai> fantasai: My inclination is to make this invalid, would be easier for everyone to understand and get it right<br>
&lt;fantasai> astearns: You would get the same effect by moving :host outside of :has()<br>
&lt;fantasai> TabAtkins: yes<br>
&lt;emilio> q?<br>
&lt;bkardell_> q+<br>
&lt;emilio> the bot is dead?<br>
&lt;TabAtkins> A:has(:is(:host B)) rewrites to :is(:host A, A:host):has(B)<br>
&lt;fantasai> bkardell_: Previous example was one that Oriol pointed out. did we agree to the opposite, that you can't use :is()? or did I misunderstand?<br>
&lt;fantasai> TabAtkins: all other relational selectors are fine<br>
&lt;fantasai> bkardell_: what was proposal?<br>
&lt;fantasai> TabAtkins: make :host illegal inside of :has() context<br>
&lt;fantasai> emilio: If no reason to disallow performance-wise, probably more work to disallow. But don't mind either way<br>
&lt;fantasai> futhark: I don't have strong feelings either way<br>
&lt;fantasai> astearns: given confusion we just put ourselves through, I have a slight preference for disalowing<br>
&lt;fantasai> astearns: because it's an unreadable way of expressing this<br>
&lt;fantasai> bkardell_: I agree<br>
&lt;fantasai> TabAtkins: :host does have theoretical use in here, because if you want to select a top-level element in your shadow tree need to use ':host > element'<br>
&lt;fantasai> TabAtkins: it's no more confusing than :root in this context<br>
&lt;fantasai> TabAtkins: so that part doesn't bother me<br>
&lt;fantasai> emilio: Why would you want to use direct child combinator? You can't have anything that's direct child of host in here<br>
&lt;fantasai> bkardell_: ...<br>
&lt;fantasai> emilio: so :host :has(stuff)<br>
&lt;fantasai> emilio: You would need to be :host(:has())<br>
&lt;TabAtkins> .foo:has(:is(:host > .top-level .bar))<br>
&lt;fantasai> TabAtkins: This is a meaningful selector<br>
&lt;fantasai> TabAtkins: it's a .foo that has a non-top-level-.bar inside it<br>
&lt;fantasai> emilio: yeah, ok, fine<br>
&lt;fantasai> emilio: Assuming there's no reason to ban it perf-wise, then seems fine to keep it<br>
&lt;fantasai> astearns: I'm hearing a lot of "eh"<br>
&lt;emilio> +1<br>
&lt;fantasai> TabAtkins: I suggest we leave as-is, unless on further investigation it has a perf implication<br>
&lt;fantasai> futhark: I agree<br>
&lt;fantasai> RESOLVED: No change<br>
&lt;fantasai> s/change/change; :host etc. continues to be allowed inside :has()/<br>
</details>


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


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

Received on Wednesday, 1 June 2022 16:26:43 UTC