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

Thank you for distilling all that down into digestible content (yum,
distillates).

A couple of notes:

The 'magic script' problem has been difficult to reconcile with <template>,
so there is willingness to continue to use <element>, but ideally without
nesting <template>. In other words, perhaps <element> can be a subtype of
<template>.

Where we really get into trouble is when we get into inheritance. I'm happy
to discuss this further, but I figure I will wait until people have had
time to think about your main content.

Scott


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