W3C home > Mailing lists > Public > public-nextweb@w3.org > December 2013

Re: [webcomponents] Auto-creating shadow DOM for custom elements

From: Elliott Sprehn <esprehn@chromium.org>
Date: Fri, 13 Dec 2013 12:52:23 -0800
Message-ID: <CAO9Q3iK1UdBmoNpOBHvehufAiMPE0=qKyfK4TF-H0JQ65ZBo7g@mail.gmail.com>
To: Maciej Stachowiak <mjs@apple.com>
Cc: Scott Miles <sjmiles@google.com>, Brian Kardell <bkardell@gmail.com>, Brendan Eich <brendan@secure.meer.net>, Domenic Denicola <domenic@domenicdenicola.com>, Erik Arvidsson <arv@chromium.org>, Ryosuke Niwa <rniwa@apple.com>, Webapps WG <public-webapps@w3.org>, public-nextweb@w3.org
On Fri, Dec 13, 2013 at 1:16 AM, Maciej Stachowiak <mjs@apple.com> wrote:

>
> On Dec 9, 2013, at 11:13 AM, Scott Miles <sjmiles@google.com> wrote:
>
> ...
>
>
> If the shadow root is optionally automatically generated, it should
> probably be passed to the createdCallback (or constructor) rather than made
> a property named "shadowRoot". That makes it possible to pass a different
> shadow root to the base class than to the derived class, thus solving the
> problem.
>

Why generate it at all then? Since you're going to need to do
super(this.createShadowRoot()) for each super call we only save the call to
createShadowRoot() on the base class with a loss of flexibility or an
increase in configuration options (ex. being able to turn off the auto
creation). Instead we should just let authors make these decisions.


>
> Using an object property named "shadowRoot" would be a bad idea in any
> case since it automatically breaks encapsulation. There needs to be a
> private way to store the shadow root, either using ES6 symbols, or some new
> mechanism specific to custom elements.
>

We discussed this many months ago on this list, but there's no way to
create real encapsulation like that because authors will just override
Element.prototype.createShadowRoot or Node.prototype.appendChild and hijack
your ShadowRoot. Making it "private" is a lie, and leads to false security
assumptions from authors. We had several teams here attempt to use
ShadowRoot as a security boundary, which is just can't be, because you're
sharing the same JS global prototypes.


> As it is, there's no way for ES5 custom elements to have private storage,
> which seems like a problem. They can't even use the closure approach,
> because the constructor is not called and the methods are expected to be on
> the prototype. (I guess you could create per-instance copies of the methods
> closing over the private data in the created callback, but that would
> preclude prototype monkeypatching of the sort built-in HTML elements allow.)
>
>
I'm not sure what you mean. How would calling the constructor help you?
Private storage can be had with ES6's SideTable (formerly WeakMap), making
it inconvenient to get the ShadowRoot from an Element just gives false
assumptions about how private it is.

- E
Received on Friday, 13 December 2013 20:53:32 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:05:54 UTC