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

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) and the weaker form ("_"
prefixing properties and marking them non-enumerable using defineProperty).
SD as currently defined is the second.

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

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

Perhaps you can imagine a simpler/faster way to do it that doesn't include
getting owners-LGTMs from nearly every part of google3 and submitting tests
in nearly every part of the tree??


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

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