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

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

As long as the above supports all other DOM element creation vectors
(innerHTML, outerHTML, etc), then this is fine. Practically speaking, if it
so happened that custom elements could *never *be instantiated with
constructors, developers on the web today wouldn't shed a tear, they use
doc.createElement(), not constructors -->
https://docs.google.com/forms/d/16cNqHRe-7CFRHRVcFo94U6tIYnohEpj7NZhY02ejiXQ/viewanalytics

-----

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

Yes, it will be along time, especially for IE9 and 10 (read: never), which
are support targets for custom element polyfills. Reliance on anything that
is optional or future should be avoided for the custom element base case.
Right now the polyfills for document.register(), and a few of the
declarative proposals, can give developers these awesome APIs today -
please, do not imperil this.


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