>> Alex Russell have been advocating that WebIDL should be allow
constructor-like interfaces
Absolutely agree. But these are horns of this dilemma.
>> #4 has been accepted for ES6 by all TC39 participants
Yes, I believe this is a timing issue. I am told it will be a long time
before #4 is practical.
Gecko and Blink have already landed forms of 'document.register', to wit:
Grail-shaped version of document.register:
// use whatever 'class-like' thing you want
class XFoo extends HTMLElement {
constructor() {
super();
this.textContent = "XFoo Ftw";
}
}
document.register('x-foo', XFoo);
But since (today!) we cannot extend HTMLElement et al this way, the landed
implementations use:
// prototype only
XFooPrototype = Object.create(HTMLElement, {
readyCallback: {
value: function() { // we invented this for constructor-like semantics
super(); // some way of doing this
}
}
};
// capture the constructor if you care
[XFoo =] document.register('x-foo', {prototype: XFooPrototype);
Which for convenience, I like to write this way (but there are footguns):
class XFooThunk extends HTMLElement {
// any constructor here will be ignored
readyCallback() { // we invented this for constructor-like semantics
super();
}
}
// capture the real constructor if you care
[XFoo =] document.register('x-foo', XFooThunk);
On Sun, Apr 14, 2013 at 12:07 PM, Allen Wirfs-Brock
<allen@wirfs-brock.com>wrote:
>
> On Apr 14, 2013, at 11:40 AM, Scott Miles wrote:
>
> >> Here are four ways to avoid the subclassing problem for custom elements
> >> 1) Only allow instances of custome dom elements to be instantiated
> using document.createElement("x-foo").
>
> Wearing web developer hat, I never make elements any other way than
> createElement (or HTML), so this would be standard operating procedure, so
> that's all good if we can get buy in.
>
>
> However, I believe that some people such as Alex Russell have been
> advocating that WebIDL should be allow constructor-like interfaces to
> support expressions such as:
> new HTMLWhateverElement()
>
> It would be future hostile to make that impossible, but support could
> reasonably wait for ES6 support.
>
>
> >> 2, 3, 4
>
> I believe have been suggested in one form or another, but as I mentioned,
> were determined to be non-starters for Gecko. I don't think we've heard
> anything from IE team.
>
>
> Well #4 has been accepted for ES6 by all TC39 participants including
> Mozilla and Microsoft and is going to happen. The basic scheme was
> actually suggested a member of the SpiderMonkey team so I'm sure we'll get
> it worked out for Gecko.
>
> Allen
>
>
>