W3C home > Mailing lists > Public > public-webapps@w3.org > January to March 2013

Re: document.register and ES6

From: Scott Miles <sjmiles@google.com>
Date: Thu, 7 Feb 2013 20:51:26 -0800
Message-ID: <CAHbmOLZQop9q_NSYngyQHhfSGB4mjj8eBga=F-0x84432zLqCw@mail.gmail.com>
To: Erik Arvidsson <arv@chromium.org>
Cc: public-webapps <public-webapps@w3.org>, daniel <daniel@mozilla.com>, Boris Zbarsky <bzbarsky@mit.edu>, Dimitri Glazkov <dglazkov@google.com>
Good reminder. On webkit/ff at least, we have made polyfills which can
generate:

<x-element> // for elements derived from HTMLUnknownElement
<button is="x-element"> // for all other elements

Since both syntaxes are now (to be) supported by spec, I think we are ok?

Scott

P.S. 100% of the custom elements in our current library are based on
HTMLUnknownElement.

P.P.S. Arv, do you have a preference from my three versions (or none of the
above)?

On Thu, Feb 7, 2013 at 7:16 PM, Erik Arvidsson <arv@chromium.org> wrote:

> Actually, that reminds me. How is a polyfill supposed to be able to create
> an element with the tag name my-button and still have the instance be an
> HTMLButtonElement? That does not seem possible. I guess a polyfill just
> need to limit the base to HTMLUnknownElement.
> On Feb 7, 2013 8:44 PM, "Scott Miles" <sjmiles@google.com> wrote:
>
>> In my excitement for getting something that worked on the Big Three
>> (webkit, IE, FF), I inadvertently cheated by adding an extra parameter to
>> 'document.register'.
>>
>> TL;DR version:
>>
>> Solutions to the extra parameter problem:
>>
>> 1. go ahead and have an (optional) extra parameter to document.register
>>
>>    MyButton = function() { ... };
>>    MyButton.prototype = { ... };
>>    MyButton = document.register('x-button', MyButton, 'button');
>>
>> 2. require user to chain prototypes himself and infer the tagName from
>> the prototype
>>
>>    MyButton = function() { ... };
>>    // making prototype requires icky DefineProperty syntax
>>    // on IE the only purpose of chaining the prototype is for tagName
>> inference
>>    MyButton.prototype = Object.create(HTMLButtonElement.prototype, { });
>>    MyButton = document.register('x-button', MyButton);
>>
>> 3. introduce an intermediate method to build the 'class':
>>
>>   MyButton = function() { ... };
>>   MyButton.prototype = { ... };
>>   MyButton = document.extendElement('button', MyButton);
>>   document.register('x-button', MyButton);
>>
>> Right now I'm preferring (3). WDTY?
>>
>> ===
>>
>> Long version:
>>
>> Recall that the goal is to support the simple notion of: make class,
>> register to tag. So,
>>
>>   class MyButton extends HTMLButtonElement...
>>   document.register('x-button', MyButton);
>>
>> My last proposed non-ES6 version had syntax like this:
>>
>>    MyButton = function() { ... };
>>    MyButton.prototype = { ... };
>>    MyButton = document.register('x-button', MyButton, 'button');
>>
>> The third parameter serves two purposes: (1) allows register to chain the
>> correct prototype (HTMLButtonElement.prototype) to MyButton.prototype and
>> (2) allows register to generate an appropriate constructor (i.e. one the
>> instantiates a 'button' element).
>>
>> Trying to remove the third parameter created some new quandries.
>>
>> One avenue is to suggest the developer set up the inheritance chain
>> outside of register. This is immediately appealing because it's very close
>> to the 'goal syntax'. IOW,
>>
>>    MyButton = function() { ... };
>>    MyButton.prototype = Object.create(HTMLButtonElement.prototype, { });
>>    MyButton = document.register('x-button', MyButton);
>>
>> Btw: this form requires inferring the tag name 'button' from
>> HTMLButtonElement.prototype, which AFAIK, is not as easy as it sounds.
>>
>> There are two potential downsides (1) adding properties to
>> MyButton.prototype requires property descriptors (or some helper function
>> the user must write), (2) on IE we aren't using the chained prototype
>> anyway.
>>
>> An alternative would be to introduce another method, something like
>> 'document.extendElement'. Usage would be like so:
>>
>>   MyButton = function() { ... };
>>   MyButton.prototype = { ... };
>>   MyButton = document.extendElement('button', MyButton);
>>   document.register('x-button', MyButton);
>>
>> Scott
>>
>>
>> On Thu, Feb 7, 2013 at 3:15 PM, Dimitri Glazkov <dglazkov@google.com>wrote:
>>
>>>
>>>
>>>
>>> On Wed, Feb 6, 2013 at 10:01 AM, Boris Zbarsky <bzbarsky@mit.edu> wrote:
>>>
>>>> On 2/6/13 5:07 PM, Erik Arvidsson wrote:
>>>>
>>>>> This refactoring is needed for ES6 anyway so it might be worth looking
>>>>> into no matter what.
>>>>>
>>>>
>>>> Well, yes, but it's a matter of timeframes.  It's incredibly unlikely
>>>> that a complete refactoring of how functions are implemented (which is what
>>>> I was given to understand would be required here) could be done in the next
>>>> several months to a year....  I doubt we want to wait that long to do
>>>> document.register.
>>>
>>>
>>> This is a valid and important concern. Boris, in your opinion, what is
>>> the most compatible way to proceed here? I see a couple of options, but
>>> don't know how difficult they will be implementation-wise:
>>>
>>> 1) Expose the ability to override [[Construct]]. Arv tells me that he
>>> spoke with V8 peeps and they think they can do this fairly easily. How's
>>> the SpiderMonkey story looking here?
>>>
>>> 2) Until ES6 is here, return a generated constructor from
>>> document.register, which is the approach that Scott/Arv/Daniel came up with
>>> for polyfills. Effectively, this generated constructor will serve as the
>>> surrogate [[Construct]] override.
>>>
>>> 3) ...
>>>
>>> 4) PROFIT
>>>
>>> :DG<
>>>
>>
>>
Received on Friday, 8 February 2013 04:51:55 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:57 GMT