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

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

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