Some suggestions:
On Fri, Apr 12, 2013 at 12:30 PM, Dimitri Glazkov <dglazkov@google.com>wrote:
> ... or "How the heck do we initialize custom elements in declarative
> syntax?"
>
> There were good questions raised about the nature of <script> element
> in the "platonic form" thread. Consider this syntax:
>
> <element name="foo-bar">
>
<element constructor="FooBar">
> <script> ...</script>
> <template> ... </template>
> </element>
>
> The way <element> should work is like this:
> a) when </element> is seen
> b) generate a constructor for this element
>
b) call the nominated ctor, new FooBar(elt).
I'm unclear on the practical advantages the instance inheriting from
HTMLElement (new FooBar(), prototype inherits) vs manipulating the element
from the outside (new FooBar(elt), prototype Object).
> b) run document.register
> c) run initialization code
>
> As I see it, the problem is twofold:
>
> 1) The <script> element timing is weird. Since <script> is
> initialization code, it has to run after the </element> is seen. This
> is already contrary to a typical <script> element expectations.
>
Why? new FooBar() has to be called, but the outer init is anytime before
that.
>
> 2) The <script> element needs a way to refer to the custom element
> prototype it is initializing. Enclosing it in a function and calling
> it with <element> as |this| seemed like a simplest thing to do, but
> Rick and John had allergic reactions and had to be hospitalized.
>
For me its the implicit declarative binding + wired in to 'this' that makes
the
original solution very magical and inflexible. I can understand ensuring
that
a component can be self-contained, but cannot understand why it needs an
ordered and hierarchical when <script> isn't rendered.
>
> So far, I haven't seen any other workable alternatives. TC39 peeps and
> others, help me find them.
>
Thanks for asking ;-)
>
> :DG<
>