Re: [webcomponents]: Platonic form of custom elements declarative syntax

One thing I'm wondering re <template> elements and the association of a
specific script with them, is what is it really doing for me? From what I
see, not much. It seems the only thing it does, is allows you to have the
generic, globally-scoped script run at a given time (via a new runwhen___
attribute) and the implicit relationship created by inclusion within the
<template> element itself - which is essentially no different than just
setting a global delegate in any 'ol script tag on the page.

Are there show-stopper issues with empowering the script tags inside
<template> elements to be a bit more powerful? (think local instance
scoping, auto template event unbinding on removal, or any other helpful
additions) If there are issues with making these script tags behave a bit
different, then what is the compelling value proposition vs something like
this: https://gist.github.com/csuwldcat/5358612 ?


On Wed, Apr 10, 2013 at 1:43 PM, Rick Waldron <waldron.rick@gmail.com>wrote:

>
>
>
> On Wed, Apr 10, 2013 at 4:38 PM, Daniel Buchner <daniel@mozilla.com>wrote:
>
>> *What about CSP that forbids inline scripts?https://wiki.mozilla.org/Apps/Security#Default_CSP_policy
>> *
>>
>> Is there any reason developers wouldn't just modify the script tag under
>> either method proposed to use src="link-to-non-inline-script" to satisfy
>> CSP requirements? The proposal I submitted certainly doesn't exclude that
>> ability/use case (or so I thought - correct if wrong)
>>
>>
> There is nothing stopping that at all.
>
> A bigger issue with proposal is that the global object appears to be the
> element's instance object itself, which isn't going to work
>
> Rick
>
>
>
>>
>> Daniel J. Buchner
>> Product Manager, Developer Ecosystem
>> Mozilla Corporation
>>
>>
>> On Wed, Apr 10, 2013 at 1:27 PM, Rick Waldron <waldron.rick@gmail.com>wrote:
>>
>>>
>>>
>>>
>>> On Wed, Apr 10, 2013 at 4:15 PM, Daniel Buchner <daniel@mozilla.com>wrote:
>>>
>>>> I have a counter proposal that takes into a count both the
>>>> easy-to-declare, 1-to-1 case, as well as the 1-template-to-many-elements
>>>> case: https://gist.github.com/csuwldcat/5358039
>>>>
>>>
>>>
>>> What about CSP that forbids inline scripts?
>>>
>>> https://wiki.mozilla.org/Apps/Security#Default_CSP_policy
>>>
>>> Rick
>>>
>>>
>>>>
>>>>
>>>> I can explain the advantages a bit more in an hour or so, I just got
>>>> pulled into a meeting...le sigh.
>>>>
>>>> Daniel J. Buchner
>>>> Product Manager, Developer Ecosystem
>>>> Mozilla Corporation
>>>>
>>>>
>>>> On Wed, Apr 10, 2013 at 12:40 PM, Scott Miles <sjmiles@google.com>wrote:
>>>>
>>>>> No, strictly ergonomic. Less nesting and less characters (less nesting
>>>>> is more important IMO).
>>>>>
>>>>> I would also argue that there is less cognitive load on the author
>>>>> then the more explicit factoring, but I believe this is subjective.
>>>>>
>>>>> Scott
>>>>>
>>>>>
>>>>> On Wed, Apr 10, 2013 at 12:36 PM, Rafael Weinstein <rafaelw@google.com
>>>>> > wrote:
>>>>>
>>>>>> On Wed, Apr 10, 2013 at 11:47 AM, Dimitri Glazkov <
>>>>>> dglazkov@google.com> wrote:
>>>>>> > Dear Webappsonites,
>>>>>> >
>>>>>> > There's been a ton of thinking on what the custom elements
>>>>>> declarative
>>>>>> > syntax must look like. Here, I present something has near-ideal
>>>>>> > developer ergonomics at the expense of terrible sins in other areas.
>>>>>> > Consider it to be beacon, rather than a concrete proposal.
>>>>>> >
>>>>>> > First, let's cleanse your palate. Forget about the <element> element
>>>>>> > and what goes inside of it. Eat some parsley.
>>>>>> >
>>>>>> > == Templates Bound to Tags ==
>>>>>> >
>>>>>> > Instead, suppose you only have a <template>:
>>>>>> >
>>>>>> > <template>
>>>>>> >     <div>Yay!</div>
>>>>>> > </template>
>>>>>> >
>>>>>> > Templates are good for stamping things out, right? So let's invent a
>>>>>> > way to _bind_ a template to a _tag_. When the browser sees a tag to
>>>>>> > which the template is bound, it stamps the template out. Like so:
>>>>>> >
>>>>>> > 1) Define a template and bind it to a tag name:
>>>>>> >
>>>>>> > <template bindtotagname="my-yay">
>>>>>> >     <div>Yay!</div>
>>>>>> > </template>
>>>>>> >
>>>>>> > 2) Whenever <my-yay> is seen by the parser or
>>>>>> > createElement/NS("my-yay") is called, the template is stamped out to
>>>>>> > produce:
>>>>>> >
>>>>>> > <my-yay>
>>>>>> >     <div>Yay!</div>
>>>>>> > </my-yay>
>>>>>> >
>>>>>> > Cool! This is immediately useful for web developers. They can
>>>>>> > transform any markup into something they can use.
>>>>>> >
>>>>>> > Behind the scenes: the presence of "boundtotagname" triggers a call
>>>>>> to
>>>>>> > document.register, and the argument is a browser-generated prototype
>>>>>> > object whose readyCallback takes the template and appends it to
>>>>>> > "this".
>>>>>> >
>>>>>> > == Organic Shadow Trees  ==
>>>>>> >
>>>>>> > But what if they also wanted to employ encapsulation boundaries,
>>>>>> > leaving initial markup structure intact? No problem, much-maligned
>>>>>> > <shadowroot> to the rescue:
>>>>>> >
>>>>>> > 1) Define a template with a shadow tree and bind it to a tag name:
>>>>>> >
>>>>>> > <template bindtotagname="my-yay">
>>>>>> >     <shadowroot>
>>>>>> >         <div>Yay!</div>
>>>>>> >     </shadowroot>
>>>>>> > </template>
>>>>>> >
>>>>>> > 2) For each <my-yay> created, the template is stamped out to create
>>>>>> a
>>>>>> > shadow root and populate it.
>>>>>> >
>>>>>> > Super-cool! Note, how the developer doesn't have to know anything
>>>>>> > about Shadow DOM to build custom elements (er, template-bound tags).
>>>>>> > Shadow trees are just an option.
>>>>>> >
>>>>>> > Behind the scenes: exactly the same as the first scenario.
>>>>>> >
>>>>>> > == Declarative Meets Imperative ==
>>>>>> >
>>>>>> > Now, the developer wants to add some APIs to <my-yay>. Sure, no
>>>>>> problem:
>>>>>> >
>>>>>> > <template bindtotagname="my-yay">
>>>>>> >     <shadowroot>
>>>>>> >         <div>Yay!</div>
>>>>>> >     </shadowroot>
>>>>>> >     <script runwhenbound>
>>>>>> >         // runs right after document.register is triggered
>>>>>> >         this.register(ExactSyntaxTBD);
>>>>>> >     <script>
>>>>>> > </template
>>>>>> >
>>>>>> > So-cool-it-hurts! We built a fully functional custom element, taking
>>>>>> > small steps from an extremely simple concept to the full-blown
>>>>>> thing.
>>>>>> >
>>>>>> > In the process, we also saw a completely decoupled shadow DOM from
>>>>>> > custom elements in both imperative and declarative forms, achieving
>>>>>> > singularity. Well, or at least a high degree of consistence.
>>>>>> >
>>>>>> > == Problems ==
>>>>>> >
>>>>>> > There are severe issues.
>>>>>> >
>>>>>> > The <shadowroot> is turning out to be super-magical.
>>>>>> >
>>>>>> > The "bindtotagname" attribute will need to be also magical, to be
>>>>>> > consistent with how document.register could be used.
>>>>>> >
>>>>>> > The "stamping out", after clearly specified, may raise eyebrows and
>>>>>> > turn out to be unintuitive.
>>>>>> >
>>>>>> > Templates are supposed to be inert, but the whole <script
>>>>>> > runwhenbound> thing is strongly negating this. There's probably more
>>>>>> > that I can't remember now.
>>>>>>
>>>>>> The following expresses the same semantics:
>>>>>>
>>>>>> <element tagname="my-yay">
>>>>>>   <template>
>>>>>>     <shadowroot>
>>>>>>       <div>Yay!</div>
>>>>>>     </shadowroot>
>>>>>>   </template>
>>>>>>   <script runwhenbound>
>>>>>>   </script>
>>>>>> </element>
>>>>>>
>>>>>> I get that your proposal is fewer characters to type. Are there other
>>>>>> advantages?
>>>>>>
>>>>>> >
>>>>>> > == Plea ==
>>>>>> >
>>>>>> > However, I am hopeful that you smart folk will look at this, see the
>>>>>> > light, tweak the idea just a bit and hit the homerun. See the light,
>>>>>> > dammit!
>>>>>> >
>>>>>> > :DG<
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>
>