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

On Feb 14, 2014, at 5:17 PM, Alex Russell <slightlyoff@google.com> wrote:

> On Fri, Feb 14, 2014 at 3:56 PM, Ryosuke Niwa <rniwa@apple.com> wrote:
> 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”.
> 
> Right, it only has the stronger form (closures)

I don’t think we have the stronger form in that using any builtin objects and their functions would result in leaking information inside the closure.

>> 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.
> 
> It's the difference between using "legit" methods and "hacking around the platform". If it's desirable to allow continued access in these situations, why isn't .shadowRoot an acceptable speed bump?

The point is that it’s NOT ALWAYS desirable to allow continued access.  We saying that components should have a choice.

> If it's not desirable, isn't the ability to get around the restriction at all a bug to be fixed (arguing, implicitly, that we should be investigating stronger primitives that Maciej and I were discussing to enable Type 4)?

Are you also arguing that we should “fix” closures so that you can safely call builtin objects and their methods without leaking information?  If not, I don’t see why we need to fix this problem only for web components.

>> 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.
> 
> So you've written off the massive coordination costs of adding a uniform to all code across all of Google and, on that basis, have suggested there isn't really a problem? ISTM that it would be a multi-month (year?) project to go patch every project in google3 and then wait for them to all deploy new code.

On the other hand, Google representatives have previously argued that adding template instantiation mechanism into browser isn’t helping anyone, because framework authors would figure that out better than we can.

I have a hard time understanding why anyone would come to conclusion that forcing every single web components that use template to have:

this.createShadowRoot().appendChild(document.importNode(template.contents));

is any less desirable than having components that want to expose shadowRoot to write:

this.shadowRoot = createShadowRoot();

> 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.
> 
> Surely as the person asking for the more restricted form, the onus falls to you to make the argument that the added restrictions show their value. 

I don’t think it’s fair to say that we’re asking for the more restricted form since Apple has never agreed to support the more open form (Type I encapsulation) in the first place.

- R. Niwa