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

I expected this more ideological argument and hence tried to sidestep (with "at least open"). Let's clarify two general use cases for Web Components:

(1) Componentisation of applications: For example, using a fractal architecture where each component composes other subcomponents structured in the same way

(2) Embedding third-party leaf components (e.g. google-maps, facebook-like, twitter-counts, etc)

Open shadows are suitable for the former and closed shadows for the latter (completely bullet-proof encapsulation). You still want to be able to benefit from things like style encapsulation, but there is more involved with application-level components, like state management.

It appears you are being dismissive of the former use case, in which case Web Components becomes relegated to just being a poor man's iframe (iframe is arguably better for the latter use case, since they are far more "strongly encapsulated": e.g. separate component registries, @font-face, etc).

For testing, you are again extrapolating your conclusion from one narrow case: I agree relying on the implementation of a *third-party* component would be brittle. But this isn't the only use case. It's reasonable to dispatch an event in one part of the application and make assertions about what changed on the other side. The view that everything should be controllable and observable from the top-level component's public API of the component is obviously impractical and brittle (every subcomponent has to proxy everything). 

Hence I think it is worth first explicitly clarifying your view on open shadows and the former use case. Is the design goal of shadows to simply maximise encapsulation so that they are not useful throughout an application and are only useful as third-party leaf nodes? If yes, then open shadows should be dropped and this made more clear. If not, then need for some sensible way to recursively walk shadows (until hitting a closed one) becomes evident and we can go back and discussing whether APIs like this are more suitable in JS or native.

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