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

I've been thinking through the implications of this "auto shadow" proposal,
and I'm glad people are seeing the utility of <template>, but I don't think
this feature would see much use.

Developers want data-binding, and the auto cloning <template> does not give
them a favorable timing model.
They want to set those up before the ShadowDOM is stamped, on a
per-instance level.
If they were to use the automatic template, it would be far too late, and
there could be unnecessary network requests or FOUC.

To remove a bit of vaguness from this scenario, Polymer elements use
data-binding in almost all cases.
Event handlers, computed properties, MVC, everywhere.
As such, no Polymer element would use the automatic <template> registration
argument.
I doubt that elements created with other libraries like Ember or Angular
would make much use of it either.

However, if some low level data-binding primitives were introduced to the
platform, there would be some real merit in an automatic template argument.
There would have to be some modifications to the proposal, such as adding
hooks for data-binding information to be given to the template instance,
but I think those details can be discussed when such a data-binding spec
arrives.

Until data-binding primitives arise, I think this automatic template is a
premature discussion.


On Sat, Dec 7, 2013 at 8:33 PM, Rafael Weinstein <rafaelw@google.com> wrote:

> On Sat, Dec 7, 2013 at 6:56 PM, Ryosuke Niwa <rniwa@apple.com> wrote:
>
>>
>> > On Dec 7, 2013, at 3:53 PM, Rafael Weinstein <rafaelw@google.com>
>> wrote:
>> >
>> > The issue is that being an element and having shadow DOM -- or any
>> display DOM, for that matter -- are orthogonal concerns.
>> >
>> > There are lots of c++ HTML elements that have no display DOM. Polymer
>> already has an even larger number.
>>
>> While that's true in browser implementations, there is very little
>> authors can do with a plain element without any shadow content it since
>> JavaScript can't implement it's own style model (i.e. creating a custom
>> frame object in Gecko / render object in WebKit/Blink) or paint code in
>> JavaScript.
>>
>> If the only customization author has to do is adding some CSS, then we
>> don't need custom element hook at all.
>>
>>
> I'm was thinking about elements whose purpose isn't presentational. For
> example, <link> or <script> in html, or <polymer-ajax> in polymer.
>
>
>> It's true that mutation observers wouldn't run immediately after
>> innerHTML if authors wanted to add some JS properties but we could fix that
>> issue in some other way; e.g. by delivering mutation records every time we
>> run a parser.
>>
>> - R. Niwa
>>
>
>