Daniel, what happens in this case?
<element name="x-foo">
<script>
class XFoo extends SVGElement {
}
</script>
</element>
This points out 2 short comings with your proposal.
1. This would just replace the global constructor. That might be OK, and we
can detect this override to register the class as needed.
2. Prefixing with HTML seems like an anti pattern.
On Fri, Apr 12, 2013 at 5:08 PM, Daniel Buchner <daniel@mozilla.com> wrote:
> @John - what about what I just sent through? It hops over the magical
> rebinding issue (or so I think), your thoughts?
>
>
> On Fri, Apr 12, 2013 at 2:06 PM, John J Barton <
> johnjbarton@johnjbarton.com> wrote:
>
>>
>> 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<
>>>
>>
>>
>
--
erik