Re: [w3c/webcomponents] Support `>>>` combinator in static profile (#78)

A use case is a concrete scenario / story. Imagining any page that doesn't use web components that use querySelectorAll to start using web components is too abstract and generic to be called as a use case.

As a counter example, I have a website (perf.webkit.org) with ~20k lines of JS/HTML/CSS code which didn't used to use web components and used querySelector and querySelectorAll. I've successfully switched to start using shadow DOM & custom elements without ever needing to find elements across shadow boundaries with querySelector or querySelectorAll.

As far as I can tell, using `>>>` to find elements across component/shadow boundaries is an anti-pattern because each component tends to have a separate internal state that needs stay in sync with its DOM tree. Mutating them directly would tend to result in each component's internal states getting out of sync with DOM nodes. For example, in apps that use React-like top-down reconstruction of DOM nodes & diff'ing, mutated DOM nodes may get thrown away and re-constructed next time the component renders itself. So for any DOM mutations made across component/shadow boundaries to make sense, the mutator must observe all DOM mutations across shadow boundaries, and re-apply the changes as needed. This leads to very inefficient, intrusive, and fragile code. That's exactly the kind of issues encapsulation should prevent.

Even for testing, the need for querySelectorAll never came up because we could just use JS functions to find the right element to do the necessary white box testing.

> And the alternative API proposal (querySelectorAgainstFlatTree) is weaker than `>>>`, because you can't control when you walk down a tree, and it can't reproduce the power of ::slotted().

This is precisely why we like that approach better. The biggest problem we have with the proposed API is the we'd have to introduce a very complicated shadow boundary transitioning code into our selector matching engine.

-- 
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-334904649