[css-scoping] `:has-shadow` pseudo-class

[LeaVerou]

It is currently impossible to detect elements with a shadow root without direct traversal and checking element.shadowRoot for every single element, which is costly.

This is useful for a variety of DOM traversal use cases, so they can identify which elements they need to do extra work on. For example fetching elements of a particular type across the entire flattened tree, or even cloning a subtree that may contain declarative shadow roots (which disappear with regular cloning).

Beyond qSA use cases, :has-shadow would allow handling the state where a CE has been defined (so :defined matches) but not yet properly initialized.

It’s probably pretty easy to add a pseudo-class for this that matches if the element has an open shadow root. Not sure if matching a closed shadow root is desirable. Combined with #11001, this becomes even more powerful.

[sorvell]

It probably makes sense that this would not match closed shadowRoots? If it did, it would leak that detail, which might be unacceptable. It'd also match built-ins with shadowRoot which is likely undesirable.

And for comparison to the slower, more verbose code one might have now:

• today: Array.from(document.querySelectorAll('*')).filter(n => n.shadowRoot)
• with this: document.querySelectorAll(':has-shadow')

[Que-tin]

Don't you think that the name :has-shadow is misleading? There's still a huge audience that has no idea what a shadow root and shadow DOM even are. For them :has-shadow might sound like a kind of box-, text- and / or drop-shadow detection.

I think there needs to be a better name for this.

[LeaVerou]

Don't you think that the name :has-shadow is misleading? There's still a huge audience that has no idea what a shadow root and shadow DOM even are. For them :has-shadow might sound like a kind of box-, text- and / or drop-shadow detection.

I think there needs to be a better name for this.

Good point. :has-shadowroot?

[Que-tin]

Could elements with shadow root attach a pseudo element and we could just do:
:has(::shadowroot)

or somethign similar? Just brain dumping rn, but imo newish features should be reused more often so people see that there are more usecase for them. I mean we already have :has()?

It feels more intuitive than a new pseudo-class.

Happy to debate @LeaVerou.

P.s. Yeah I mean it literally makes no sense to style the ::shadowroot and therefore the element is kinda useless, but still.

[LeaVerou]

Introducing such a pseudo-element is way, WAY more work for UAs than the pseudo-class I'm proposing, and the use cases are unclear.

imo newish features should be reused more often so people see that there are more usecase for them

We do that anyway (we tend to have a different perception of what a new feature is anyway — by the time CSS features become widely implemented and known to authors, they have been floating around in specs for 2-5 years), but we don't introduce features with no use cases just to do that, especially when nontrivial to implement.

[LeaVerou]

Turns out there's an earlier topic: #2908
Though not sure about closing this since there has been a fair bit of discussion

[erosman]

And for comparison to the slower, more verbose code one might have now:

• today: Array.from(document.querySelectorAll('*')).filter(n => n.shadowRoot)

Please also note that there are nested shadow DOM instances which require recursive search. e.g. cookies.set()

[hiroya-uga]

Hi! I'd like to share a use case.

I use a third-party widget that requires domain registration before it initializes. The host structure looks like this:

<li>
  <div id="widget">
    <script src="..."></script>
    <script src="..."></script>
  </div>
</li>

Until my domain is approved, no shadow root is attached and the <li> renders as an empty placeholder. Once registered, an open shadow root is created and the widget renders.

I want to hide the <li> with CSS until the shadow root appears:

li:not(:has-shadowroot) {
  display: none;
}

or

li:not(:has(::shadow-root)) {
  display: none;
}

This may be a niche case, but it represents a pure CSS styling use case — distinct from the JS/DOM traversal use cases already discussed here and in #2908.
So I decided to leave a comment.

Personally, I prefer the :has-shadowroot syntax. Since this feature is intended for DOM traversal only, I think directly styling :host from outside should remain impossible — for both open and closed shadow roots — in order to preserve encapsulation.

I hope this helps the discussion.

(Note: English is not my first language and I used a translation tool for this comment. I apologize if anything is unclear.)