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 <a...@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" <sjmi...@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 <dglaz...@google.com>wrote:
>>
>>>
>>>
>>>
>>> On Wed, Feb 6, 2013 at 10:01 AM, Boris Zbarsky <bzbar...@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<
>>>
>>
>>
