Re: HTMLElement.register--giving components tag names

On Wed, Aug 31, 2011 at 1:38 PM, Erik Arvidsson <arv@chromium.org> wrote:
> On Tue, Aug 30, 2011 at 22:33, Dominic Cooney <dominicc@chromium.org> wrote:
>
>> You will notice that this says nothing about how prototypes are wired
>> up. It should. Maybe the argument to extend should have an optional
>> second field, proto, that specifies the new methods/getters/setters
>> that ContactPicker's prototype should introduce.
>>
>> This is not a general subtyping mechanism! It is only designed for
>> setting up subtypes of HTMLElement for use with register. When
>> ECMAScript and the DOM bindings are sufficiently aligned,
>> HTMLElement.register can be opened up to accept constructors defined
>> using ordinary ECMAScript mechanisms for subtyping DOM interfaces.
>> Scripts can continue to use extend (it is pretty succinct) or
>> constructors set up their own way.
>
> Providing a prototype is important.

So here’s a refinement. I will add this to the wiki:

interface ExtensibleElement {
  object extend(ElementRegisterOptions options) raises (DOMException);
}
HTMLElement implements ExtensibleElement;
…

[Callback]
interface ExtensionElementInitializer {
  void init(HTMLElement element);  // should this have a return value,
to allow replacement?
}

dictionary ElementRegisterOptions {
  ExtensionElementInitializer init;
  object? proto;  // ECMAScript-ism?
}

Author: If options.proto is specified,
HTMLElement.prototype.isPrototypeOf(options.proto) should be true, and
options.proto should not be a platform object, nor have a platform
object on the prototype chain.

UA: If options.proto is specified, and
HTMLElement.prototype.isPrototypeOf(options.proto) is false, or
options.proto is a platform object, or options.proto has a platform
object on the prototype chain, register may throw a TYPE_ERROR.

If options.proto is not specified, the resulting constructor’s
prototype property will be HTMLElement.prototype or
HTMLElement.prototype.isPrototypeOf(<<resulting prototype>>) will be
true. This object might have been synthesized by the UA.

UA: When the constructor is invoked, (same conditions on the proto as
before) the constructor may throw a TYPE_ERROR.

> For example I can imagine UI toolkits providing their own "base class"
> that all the custom elements extend.

That is most straightforward when you have

FancyWidgetBase : HTMLElement
FancyButton : FancyWidgetBase

It does not work so well when you want FancyButton to be a
HTMLButtonElement. Then you need a factory of FancyWidgetBases that
hook one up to HTMLButtonElement, HTMLDivElement, etc.

> Also, it seems essential to allow extending other things than just HTMLElement.

Wearing my author hat, that sounds appealing. Browser internals may do
things like switch on an element’s tag name. It would need to start
consulting the table of extensions when it did that in order to
realize that x-fancy-button is a button element.

Received on Wednesday, 31 August 2011 21:42:37 UTC