[selectors][css-scoping] Should :host(:has()) match?

[alisonmaher]

The group recently resolved to allow :host:has() per #10693 (comment). This allows an author to select the host element if it has a descendent in the shadow DOM matching a provided relative selector list.

:host(:has()) is similar to :host:has() except it would match against descendants in the light DOM. It was noted in that issue that :host(:has()) is already defined to work per the following comment #10693 (comment) and tests added in web-platform-tests/wpt#47441.

Safari already supports the tests for :host(:has()) added in web-platform-tests/wpt#47441, and Firefox supports some. Chromium does not yet support :host(:has()), but it does support :host:has().

There was some confusion on whether :host:(has()) is allowed, but per spec, it is not currently supported. The CSS Selectors spec notes that "Since :has() takes a <relative-selector-list>, its arguments are inherently complex selectors (because they start, perhaps implicitly, with a combinator). This means :has() cannot be used in contexts that don’t allow complex selectors; its arguments will be guaranteed to be invalid." And :host() is defined to take a <compound-selector>.

Given that some browsers already support :host:(has()), given we already support :host:has() variant, and given author use cases (as called out in #7953 (comment)) I am wondering if we should reconsider either:

1. If :has() should be a <complex-selector> (which was discussed in [selectors][css-scoping] Should :host:has() match? #10693)
2. Update what is allowed in :host() (which was previously discussed in [css-scoping-1] Clarify exactly what :host(<sel>) can use as argument #7953)

I suspect the latter of the two is more likely the route to take but would be open to thoughts from the wider community.

CC @tabatkins @Westbrook @justinfagnani

[tabatkins]

:host():has() and :host(:has()) have different performance characteristics. :host:has() is identical to div:has(); the only question was whether :has() was allowed to match :host due to it being featureless.

:host(:has()), on the other hand, requires you to match on arbitrary elements outside the shadow tree. I know @emilio preferred keeping it disallowed for this reason. Similarly, altho Safari supports :host(:has()), they are asking to remove :host-context() (in #1914), so I presume the same arguments apply and they'd prefer dropping their :host(:has()) support as well. (@nt1m?) (The two are pretty much the same thing, just matching in different directions on the outer tree.)

[nt1m]

@rniwa or @anttijk might have opinions here.

[Westbrook]

:host-context() and :host(:has()) do not have the same shadow piecing performance profile, so while one can lament the loss of :host-context() there's no specific need to associate it directly to :host(:has()). In fact, it is WebKit's incredibly diverse support for it that brought it to the community that Mozilla has partial support for the selector and Blink has none.

The direct correlation between div:has() and :host(:has()) is important in clarifying the benefits of the selector and it is hard to see how the performance characteristics of the two could be different. :host(...) already speaks to the light DOM just the same as selector build from div would, there is nothing about the use of :host(:has()) that would point to a different relationship.

The indirect relationship between div:has() and :host:has() points to similar (though less explicitly the same) performance characteristics, in that the use of host here points to the <#shadow-root> rather than the <host-element>, but in practice points to the same performance characteristics in that the rules effected by it all live within a single document.

Myself and the Web Components Community Group very much hope that in accordance with these similarities that it would be possible to afford shadow DOM users the same access to these sorts of parent selecting devices that a flat DOM or @scope {} rule user would get in this context.

[sorvell]

Just want to echo @Westbrook that this would be great to support.

I hope the actual style calculation cost could be made similar to other :has applications since the :host is in the same tree the :has selector matches against.

This would unlock some really interesting behaviors. For example, if the host has a certain light DOM tree shape, set a custom property that can be consumed arbitrarily in its shadow DOM directly or via a style query.

[tabatkins]

:host-context() and :host(:has()) do not have the same shadow piecing performance profile, so while one can lament the loss of :host-context() there's no specific need to associate it directly to :host(:has()).

I'm not sure what you mean by this. They're doing nearly exactly the same thing - matching based on the light tree outside of the shadow, relative to the host somehow. If anything, :host(:has(...)) is worse than :host-context() because it :has() is generally expensive while :host-context() is limited to a single compound selector in the ancestor tree, basically just running arg#host, arg #host in the light tree, instead of #host:has(arg).

[Westbrook]

:host-context() doesn't have a ceiling bound. No matter the shadow boundaries ABOVE a :host the "context" must be presented whereas :host(:has(...)) outlines a relationship between an element :host and the light DOM children related to it.

<body class="this-context">
  <this-el>
    #shadow-root 
      <that-el>
        #shadow-root  
          <style>
            :host-context(.this-context) {
               /* styles because of realities outside of the current DOM tree */
            }
         </style>
    </that-el>
  </this-el>
</body>

VS

<this-el>
  #shadow-root
    <style>
      :host(:has(that-el)) {
          background-color: green;
      }
      :host(:has(other-el)) {
          /* never acheived */
          background-color: red;
       }
    </style>
    <slot></slot>
  <that-el>
    #shadow-root      
      <other-el></other-el>
  </that-el>
</this-el>

[css-meeting-bot]

The CSS Working Group just discussed [selectors][css-scoping] Should :host(:has()) match?.

The full IRC log of that discussion

<emeyer> alisonmaher: We previously resolved to allow host:has(), matching against shadow DOM descendants
<TabAtkins> :host:has() (allowed), :host(:has()) (what we're discussing here)
<emeyer> …But the spec doesn’t allow matching into the light DOM
<emeyer> …If we were to allow this, we’d have to change something
<emeyer> …I think we’d have to change what we allow by :host
<TabAtkins> q+
<astearns> ack TabAtkins
<emeyer> …Want to open this for discussion
<emeyer> TabAtkins: The main objection for this was coming from Apple developers, so I’d like to have them in the room when we discuss this
<emilio> q+
<emeyer> …My opinion is we should allow everything because I like features, but I also appreciate performance concerns
<astearns> ack emilio
<emeyer> …I can’t represent their opinion
<emeyer> emilio: This might not be an issue because of where CHroms sotres (or maybe stored?) invalidations, but we really don’t want to do the same
<emeyer> …I do think it can be problematic
<emeyer> …I can check with the person who implemented :has() in Gecko, but I think this makes invalidating :has() rather complicated and I’m not sure how to go about it
<emeyer> s/CHroms sotres/Chrome stores/
<emeyer> …I can take an issue to check with David Shin, but I don’t see a great way of making this fast
<emeyer> astearns: I know Ryuske hosted Breakout Day sessions that were at least related to this; anyone attend those?
<emeyer> (no)
<emeyer> …I’ll look to see if there’s anything there I can bring back to the issue
<emeyer> …We’ll have to come back to this later
<emeyer> alisonmaher: Sounds good to me

[astearns]

(I looked at the breakout sessions I mentioned, and did not see discussion of this issue)

[emilio]

I think some of the things I said weren't quite minuted. But the issue here is that, given if shadow dom and light dom rules are stored separately (which is useful for a lot of reasons):

• Changes in the light dom need to somehow go look at the shadow root of an arbitrary ancestor (or not even ancestor, see next comment), in order to find the :has() rules.

• Inserting a shadow host becomes very non-local, specially if we allow combinators like :host(:has( ~ foo)) or so, suddenly it affects arbitrary elements on their following siblings and sibling-descendants etc.