Open LeaVerou opened 1 month ago
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:
Array.from(document.querySelectorAll('*')).filter(n => n.shadowRoot)
document.querySelectorAll(':has-shadow')
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.
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
?
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.
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.
Turns out there's an earlier topic: #2908 Though not sure about closing this since there has been a fair bit of discussion
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.