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

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?


>
> 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).

(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))


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


>
> - R. Niwa
>
>