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

I'm late to the party...so pardon if this is a dumb idea but....
Could the solution to this problem be as simple as adding an
"applyTemplate" callback to the lifecycle and prohibiting access to the
shadowRoot prior to that point in time?


On Mon, Dec 9, 2013 at 2:13 PM, 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
>
>  }
> }
>
> 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.
>>
>
>


-- 
Rob Eisenberg,
President - Blue Spire
www.durandaljs.com