On Sat, Apr 13, 2013 at 10:16 PM, Allen Wirfs-Brock <al...@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 > > >
