[whatwg/dom] A faster way to find open shadow roots (or shadow hosts) (#665)

There are requests from web developers who need faster access to all trees under a document, e.g. to find out specific elements that matches some criteria. Now you have to run `querySelector()` recursively for each document and its descendant shadow roots. You don't have any faster way than iterating all elements to see if their `.shadowRoot` is null or not.

[A popular use case that I have heard](https://groups.google.com/a/chromium.org/d/msg/blink-dev/ScMLN_Hj52E/M2PjkIZUEAAJ) is for testing, and one possibility is to add a new interface to webdriver.  But developers also demand some fast solution usable on the web, even if it's applicable to open shadow roots. As adding a new combinator to CSS selector was strongly opposed, it is not an option at least for now.

Other possibilities so far:
- [A new pseudo class](https://github.com/w3c/webcomponents/issues/426#issuecomment-200950974) (e.g. `:shadowhost`) that matches a shadow host
- A new flag or filter for [TreeWalker](https://dom.spec.whatwg.org/#treewalker) API for matching a shadow host or a shadow root.
- [A new API](https://github.com/w3c/webcomponents/issues/78#issuecomment-265601511) that can accept limited set of selector (e.g. a simple selector) against all elements in all trees

First two options may achieve the same goal, though no one yet has submitted a concrete spec proposal.  The last option was from Apple, but no standardization effort so far.

I once ran an experiment of performance, see https://github.com/w3c/webcomponents/issues/78#issuecomment-264403496. From the results, any of the above once implemented native, would have significant speedup.

Background history: In the Shadow DOM V0 era Google proposed `/deep/` combinator (later renamed to `>>>`) in CSS selector and found that the usage in stylesheet was problematic for performance, and restricted the usage only in `querySelector()` (aka snapshot or static profile). But it did not reach agreement with other vendors (see https://github.com/w3c/webcomponents/issues/78).  The rationale we had in selector was that it gives both performance and flexibility of CSS selectors, at the cost of implementation complexity.

References:
https://bugs.chromium.org/p/chromium/issues/detail?id=829713
https://github.com/w3c/webcomponents/issues/78
https://github.com/w3c/csswg-drafts/issues/640
https://www.chromestatus.com/feature/5045542597951488

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/dom/issues/665