I almost forgot, there is a secondary problem with 'normal constructors',
see here:
http://lists.w3.org/Archives/Public/public-webapps/2013JanMar/0728.html
Sorry in advance, lol.
On Sun, Apr 14, 2013 at 12:22 PM, Scott Miles <sjmiles@google.com> wrote:
> errata: XFooPrototype = Object.create(HTMLElement.prototype, {
>
>
> On Sun, Apr 14, 2013 at 12:21 PM, Scott Miles <sjmiles@google.com> wrote:
>
>> >> 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
>>>
>>>
>>>
>>
>