Re: [webcomponents] Encapsulation and defaulting to open vs closed (was in www-style)

On Feb 14, 2014, at 2:50 PM, Elliott Sprehn <esprehn@chromium.org> wrote:
> On Fri, Feb 14, 2014 at 2:39 PM, Boris Zbarsky <bzbarsky@mit.edu> wrote:
> On 2/14/14 5:31 PM, Jonas Sicking wrote:
> Also, I think that the Type 2 encapsulation has the same
> characteristics. If the component author does things perfectly and
> doesn't depend on any outside code
> 
> And never invokes any DOM methods on the nodes in the component's anonymous content.  Which is a pretty strong restriction; I'm having a bit of trouble thinking of a useful component with this property.
> 
> 
> I think my biggest issue with Type-2 is that unlike the languages cited for providing "private" it's trying to mimic it provides no backdoor for tools and frameworks to get at private state and at the same time it doesn't add any security benefits.

Except that JavaScript doesn’t have “private”.

> Ruby, Python, Java, C# and almost all other modern languages that provide a private facility for interfaces (as advocated by the Type-2 design) provide a backdoor through reflection to get at the variables and methods anyway. This allowed innovation like AOP, dependency injection, convention based frameworks and more.
> 
> So if we provide Type-2 I'd argue we _must_ provide some kind of escape hatch to still get into the ShadowRoot from script. I'm fine providing some kind of "don't let CSS styles enter me" feature, but hiding the shadowRoot property from the Element makes no sense.

I don’t see how the above two sentences lead to a consolation that we must provide an escape hatch to get shadow root from script given that such an escape hatch already exists if the component authors end up using builtin DOM functions.

> We all agree it's not a security boundary and you can go through great lengths to get into the ShadowRoot if you really wanted, all we've done by not exposing it is make sure that users include some crazy jquery-make-shadows-visible.js library so they can build tools like Google Feedback or use a new framework or polyfill.

I don’t think Google Feedback is a compelling use case since all components on Google properties could simply expose “shadow” property themselves.

Since you have preciously claimed that instantiating a template element may not be a common pattern for custom elements / web components, I have a hard time accepting the claim that you’re certain accessing shadow root is a common coding pattern.

> So given that we should have ShadowRoot.getPrivateType2Root(element) to provide a sensible modern api like other languages, is providing the shadowRoot property on the Element any different?

We’re disagreeing on the premise that we should have ShadowRoot.getPrivateType2Root.

> I think we need to steer this conversation back to CSS's ability to style the ShadowRoot. There's no reason we can't provide a "no styles can enter me flag" while still having the shadowRoot property and the node distribution APIs.

That might be an interesting topic to discuss but www-style discussion appears to indicate that we need to settle encapsulation discussion in public-webaps regardless.

- R. Niwa