Re: [webcomponents]: Of weird script elements and Benadryl

On Sat, Apr 13, 2013 at 10:16 PM, Allen Wirfs-Brock

> 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.


> Allen

Received on Sunday, 14 April 2013 18:29:31 UTC