[webcomponents]: Platonic form of custom elements declarative syntax

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<

Received on Wednesday, 10 April 2013 18:48:25 UTC