[selectors-4] Consider disallowing :host, :host(), :host-context() inside :has()

[byung-woo]

The only meaningful usage of :host inside :has() is using it with :scope.

• .b:has(:host .a :scope .c) { color: green }

In the above example, the :scope inside the :has() matches the subject element of the style rule according to the current relative selector absolutizing spec

But as pointed in some other issues (issue 6399, issue 7211), the above expression has the same problem in the below expression. (increasing invalidation complexity)

• .b:has(:is(:host .a :scope) .c) { color: green }

So, it would be better to use below expression instead of the above.

• :host .a .b:has(.c) { color: green }

How about disallowing :host, :host(), :host-context() inside :has() to avoid increasing complexity?

[css-meeting-bot]

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

• RESOLVED: No change

The full IRC log of that discussion

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