On Sat, Apr 13, 2013 at 10:16 PM, Allen Wirfs-Brock
<allen@wirfs-brock.com>wrote:
>
>
> I see two ways you might do this:
>
> 1) create a new *anonymous* constructor object that inherits from
> HTMLElement. It wouldn't have any unique behavior but it would be uniquely
> associated the particular <element> that defined it and it might be useful
> for doing instanceof tests. It would be the constructor that you register
> with the tag.
>
This is much better then the semantics I described for handling cases where
no explicit constructor exists—nice!
> 2) Have a new kind of HTML*Element that is used when instantiating all
> custom elements that don't have explicit constructors. As a placeholder
> name I'll use HTMLAppDefinedElement. One system defined
> HTMLAppDefinedElement constructor can be used for all such custom elements
> because they have no distinguishing behavior. So every <x-foo> would have
> a dom node that was an instance of HTMLAppDefinedElement and so would every
> <x-bar>. The instances only differ in their identify and the value of the
> tag names (and their children, etc.).
>
> Note in both these cases there are no <element> specific behaviors and
> hence no need to install prototype properties. I think if an element needs
> such custom behavior it should be required to use a "constructor="
> attribute to associate an app provided constructor object with the element
> and the constructor should be specified in a normal <script> bock using
> normal JS techniques.
>
> It would be a mistake to automatically generate the constructor and then
> to invent some new convention to be used in a special kind of nested script
> block for installing properties into a prototype of the generated
> constructor. This is one of the main things I was objecting to, JS already
> has multiple ways to define constructors and ES6 will have a very
> straightforward way using class declarations. We don't need a new ad hoc
> way for this specific use case.
>
> For what it's worth, I have nothing against making constructor="" an
> option that is used instead of the tag name, but why force extra
> boilerplate if people would be just as comfortable dealing with a
> constructor name based on the tag name they specify? (as elements do now)
>
> The purpose of "constructor=" should be to explicitly say, this <element>
> uses a app defined element constructor which is hereby identified. The
> absence should indicate that a platform provided element constructor will
> be used
>
Exactly and I apologize if I was previously unclear about this.
Rick
>
> Allen
>
>
>