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

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

 }
}

Scott


On Mon, Dec 9, 2013 at 7:20 AM, Brian Kardell <bkardell@gmail.com> wrote:

> +public-nextweb _ i encourage folks there to check out
> public-webapps@w3.org as this conversation is deep and multi-forked and I
> am late to the party.
>
> On Dec 7, 2013 4:44 PM, "Brendan Eich" <brendan@secure.meer.net> wrote:
> >
> > What does polymer do? Cows are already treading paths.
> >
> > I still smell a chance to do better out of the gate (gave, thanks
> autospellcheck! lol). Call me picky. Knee-jerking about scenario solving (I
> think I taught Yehuda that one) doesn't help. Particular response, please.
> >
> > /be
> >
>
> I think the most important part is to first ensure that we -can- explain
> the magic with core apis even if they are initially saltier than we'd all
> like.  When reasonable opportunities present themselves to improve
> developer ergonomics, we should take them - it doesn't preclude other
> opportunities for better flowers to bloom.
>
> The issues in this specific case in my mind surround the observation that
> it feels like it is attempting to bind several layers together which are in
> various states of "done" and conceptually what we have is more like a
> squirrel path than a cow path on this piece.  Without bindings or some kind
> of  pattern for solving those use cases, template is a less thing - and i
> think we are far from that.    Templates aren't necessary for a useful
> document.register().  Shadow DOM isn't either but it's more obvious where
> the connections are and it seems considerably more stable.  There also
> isn't necessarily a 1:1 relationship of component to template, so we have
> to be careful there lest we add confusion.  Is this really a ShadowHost?
>
> I am not actually sure that the initial message in this thread really
> needs to have anything particular to the template element though, it looks
> like the optional third argument could be any Node - and that does actually
> seem to describe a useful and common pattern which we could easily explain
> in existing terms and it might be fruitful to think about that.
>