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

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

From: Maciej Stachowiak <mjs@apple.com>
Date: Fri, 13 Dec 2013 01:16:58 -0800
Cc: Brian Kardell <bkardell@gmail.com>, Brendan Eich <brendan@secure.meer.net>, Domenic Denicola <domenic@domenicdenicola.com>, Elliott Sprehn <esprehn@chromium.org>, Erik Arvidsson <arv@chromium.org>, Ryosuke Niwa <rniwa@apple.com>, Webapps WG <public-webapps@w3.org>, public-nextweb@w3.org
Message-id: <7A990047-AF5E-4C35-B1D2-D1F62EA2BC2F@apple.com>
To: Scott Miles <sjmiles@google.com>

On Dec 9, 2013, at 11:13 AM, Scott Miles <sjmiles@google.com> wrote:

> Domenic Denicola a few messages back gave a highly cogent explanation of the exact line of thinking arrived at last time we went through all this material. 
> 
> I'm not wont to try to summarize it here, since he said it already better there. Perhaps the short version is: nobody knows what the 'standard use case' is yet.
> 
> In previous adjudications, the straw that broke that camel's back was with respect to handling auto-generation with inheritance. Shadow-roots may need to be generated for each entry in the inheritance chain. Having the system perform this task takes it out of the control of the user's code, which otherwise has ability to modulate calls to super-class methods and manage this process.
> 
> class XFoo {
>   constructor_or_createdCallback: function() {
>     // my shadowRoot was auto-generated
>     this.doUsefulStuffLikeDatabinding(this.shadowRoot);
>   }
> }
> 
> class XBar extends XFoo {
>   constructor_or_createdCallback: function() {
>     super(); // uh-oh, super call operates on wrong shadowRoot
>   }
> }

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.

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

Regards,
Maciej
Received on Friday, 13 December 2013 09:17:35 UTC

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