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

Fwiw, I believe we can polyfill just about anything, this is not the issue
(afaict).

But even targetting latest Firefox and IE 11, the time frame looks to be
many months before we can actually subclass builtins.


On Sun, Apr 14, 2013 at 12:46 PM, Daniel Buchner <daniel@mozilla.com> 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.*
>
> 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
>>>>
>>>>
>>>>
>>>
>>
>