Re: [w3c/webcomponents] Support /deep/ in static profile (bugzilla: 28591) (#78)

Let me continue discussion on this thread, here's the summary so far.

The original proposal was, to allow ['>>>' (shadow-piercing combinator)](https://drafts.csswg.org/css-scoping/#deep-combinator) in the [static profile](https://drafts.csswg.org/selectors-4/#static-profile) only.

Chrome had `/deep/` combinator for Shadow DOM v0, which could be used for both static/dynamic
profiles but found that using it in CSS stylesheets (i.e. dynamic profile) caused significant performance issues, as it is often used for theme-like rules (e.g. `body >>> .fancycheckbox { ... }`), at every style recalculation the engine had to match the selector against all the nodes.

The idea was to limit this combinator for querySelector/querySelectorAll, which runs one-off. The answer to theme-like styling as of now is to use CSS custom properties, but no good solutions for JS other than recursively applying querySelector on each shadow root ([example](https://developers.google.com/web/fundamentals/primers/shadowdom/?hl=en#finall)).

The concerns so far are
- use cases are primarily for testing (WebDriver etc.)
- breaks encapsulation of Shadow DOM
- operation is ineffective (this is for cases when it is used for observer-like pattern?)

If Shadow DOM is closed mode-only, this combinator of course doesn't make sense, but for open shadow trees, providing a way to select node in shadow tree should make sense.

One alternative idea from @annevk was to have `.deepQuery()` instead of the combinator,
but what it matches against e.g. `.deepQuery('.a .b')` and `.querySelector('.a >>> .b')` is different.
(in `.deepQuery()` all normal descendant combinator mean deep descendant, or `.a` and `.b`
have to be in the same tree?  It could be either way, but I guess explicit distinction is better
(normal descendant vs. deep desendant).


---
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/webcomponents/issues/78#issuecomment-238452345