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

On 14 Feb 2014 17:39, "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.

This is non sequitur. One relates to a way of implementing a way to
generate something, another with the default access policy of related (but
not identical) things. They are different in kind.

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

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