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

On Feb 14, 2014, at 6:12 PM, Daniel Freedman <dfreedm@google.com> wrote:
> On Fri, Feb 14, 2014 at 5:39 PM, Ryosuke Niwa <rniwa@apple.com> wrote:
> 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));
> 
> I don't understand how this pertains to encapsulation. Could you elaborate?

See http://lists.w3.org/Archives/Public/public-webapps/2013OctDec/0855.html
"I don't see how pushing that one line down into the browser is helping anyone. Web components are part of the extensible web concept where we provide a minimal subset of features necessary for opinionated frameworks to build things on top. Supporting <template> in document.register is easily done in script, so I believe it's better left to developers as they're better at building frameworks than we are.”

which was an argument made against automatically instantiating shadow root for custom elements.  If you truly believe that Web developers are better at building frameworks than we are, then why are we, by default, exposing shadow root on the host element?


> is any less desirable than having components that want to expose shadowRoot to write:
> 
> this.shadowRoot = createShadowRoot(); 
> 
> The other hand of this argument is that components that wish to lock themselves down could write:
> 
> this.shadowRoot = undefined;
> 
> Of course, this does would not change the outcome of the Shadow Selector spec, which is why a flag for createShadowRoot or something would be necessary to configure the CSS engine (unless you're ok with having the existence of a property on some DOM object control CSS parsing rules).

We most vigorously object to making the CSS style resolver depend on JS DOM object properties.  That’s not an acceptable design due to security and performance implications.

> (Also your example would not handle multiple shadow roots correctly, here's one that would)
> var sr = this.shadowRoot;
> var newSr = this.createShadowRoot();
> newSr.olderShadowRoot = sr;
> newSr.appendChild(document.importNode(template.content))

This could be written much better as:

var newShadowRoot = this.createShadowRoot();
newShadowRoot.olderShadowRoot = this.shadowRoot;

assuming that there is no builtin “shadowRoot” property exposed on element.


>> 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.
> 
> I don't understand this point, can you elaborate? It certainly seems like you are asking for a form of ShadowDOM encapsulation that is more restrictive than the already defined Type 1.

On Feb 14, 2014, at 6:55 PM, Alex Russell <slightlyoff@google.com> wrote:
> > 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.
> 
> Wait....what? Either what you want *is* more restricted than Type 1 or it's not. If it is, the burden falls to you to outline use-cases and identify users (as type 1 proponents have).
> 
I’m saying that YOU are the one asking for Type I encapsulation on the basis that we’ve never agreed that Type I encapsulation is necessary or desirable for the level 1 specifications.  The only consensus we’ve had in this working group so far was to add a switch between two modes since Google representatives have insisted that they want Type I encapsulation and Apple representatives have insisted that we want Type II encapsulation.  Neither party has convinced each other that either type is desirable, let alone which one is a better default, as far as I can tell.

- R. Niwa