<element name="x-foo">
<script>
class XFoo extends SVGElement {
}
</script>
</element>
This points out 2 short comings with your proposal.
---
I'm not sure that qualifies as a shortcoming, I simply didn't consider the
non-HTML prefixs when I was thinking about the example - but we could just
as well drop the prefixing and create an attribute on the <element> tag
that developers used to specify base inheritance, which would default to
"HTMLElement" but allow for anything, for example:
<element tagname="x-foo" inherits="SVGElement">
<template>...</template>
<script>
XFooElement.prototype.bar = function(){...}
XFooElement.prototype.readyCallback = function(){...}
</script></element>
</element>
As an added plus, declaring inheritance in the <element> tag reduces
boilerplate code. So now that we've dispensed with the prefixing issue
(which actually benefited the proposal), do you have any other thoughts?
On Fri, Apr 12, 2013 at 2:13 PM, Erik Arvidsson <arv@chromium.org> wrote:
> 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
>
>
>