Re: Custom elements ES6/ES5 syntax compromise, was: document.register and ES6

Perhaps I'm making a mistake, but there is no specific prototype for the
native header element. 'header', 'footer', 'section', e.g., are all
HTMLElement, so all I can do is

FancyHeaderPrototype = Object.create(HTMLElement.prototype);

Afaict, the 'headerness' cannot be expressed this way.


On Tue, Feb 19, 2013 at 8:34 PM, Daniel Buchner <daniel@mozilla.com> wrote:

> Wait a sec, perhaps I've missed something, but in your example you never
> extend the actual native header element, was that on purpose? I was under
> the impression you still needed to inherit from it in the prototype
> creation/registration phase, is that not true?
> On Feb 19, 2013 8:26 PM, "Scott Miles" <sjmiles@google.com> wrote:
>
>> Question: if I do
>>
>> FancyHeaderPrototype = Object.create(HTMLElement.prototype);
>> document.register('fancy-header', {
>>   prototype: FancyHeaderPrototype
>> ...
>>
>> In this case, I intend to extend "header". I expect my custom elements to
>> look like <header is="fancy-header">, but how does the system know what
>> localName to use? I believe the notion was that the localName would be
>> inferred from the prototype, but there are various semantic tags that share
>> prototypes, so it seems ambiguous in these cases.
>>
>> S
>>
>>
>> On Tue, Feb 19, 2013 at 1:01 PM, Daniel Buchner <daniel@mozilla.com>wrote:
>>
>>> What is the harm in returning the same constructor that is being input
>>> for this form of invocation? The output constructor is simply a
>>> pass-through of the input constructor, right?
>>>
>>> FOO_CONSTRUCTOR = document.register(‘x-foo’, {
>>>   constructor: FOO_CONSTRUCTOR
>>> });
>>>
>>> I guess this isn't a big deal though, I'll certainly defer to you all on
>>> the best course :)
>>>
>>> Daniel J. Buchner
>>> Product Manager, Developer Ecosystem
>>> Mozilla Corporation
>>>
>>>
>>> On Tue, Feb 19, 2013 at 12:51 PM, Scott Miles <sjmiles@google.com>wrote:
>>>
>>>> >> I'd be a much happier camper if I didn't have to think about
>>>> handling different return values.
>>>>
>>>> I agree, and If it were up to me, there would be just one API for
>>>> document.register.
>>>>
>>>> However, the argument given for dividing the API is that it is improper
>>>> to have a function return a value that is only important on some platforms. If
>>>> that's the winning argument, then isn't it pathological to make the 'non
>>>> constructor-returning API' return a constructor?
>>>>
>>>>
>>>> On Mon, Feb 18, 2013 at 12:59 PM, Daniel Buchner <daniel@mozilla.com>wrote:
>>>>
>>>>> I agree with your approach on staging the two specs for this, but the
>>>>> last part about returning a constructor in one circumstance and undefined
>>>>> in the other is something developers would rather not deal with (in my
>>>>> observation). If I'm a downstream consumer or library author who's going to
>>>>> wrap this function (or any function for that matter), I'd be a much happier
>>>>> camper if I didn't have to think about handling different return values. Is
>>>>> there a clear harm in returning a constructor reliably that would make us
>>>>> want to diverge from an expected and reliable return value? It seems to me
>>>>> that the unexpected return value will be far more annoying than a little
>>>>> less mental separation between the two invocation setups.
>>>>>
>>>>> Daniel J. Buchner
>>>>> Product Manager, Developer Ecosystem
>>>>> Mozilla Corporation
>>>>>
>>>>>
>>>>> On Mon, Feb 18, 2013 at 12:47 PM, Dimitri Glazkov <dglazkov@google.com
>>>>> > wrote:
>>>>>
>>>>>> On Fri, Feb 15, 2013 at 8:42 AM, Daniel Buchner <daniel@mozilla.com>
>>>>>> wrote:
>>>>>> > I'm not sure I buy the idea that "two ways of doing the same thing
>>>>>> does not
>>>>>> > seem like a good approach" - the web platform's imperative and
>>>>>> declarative
>>>>>> > duality is, by nature, two-way. Having two methods or an option
>>>>>> that takes
>>>>>> > multiple input types is not an empirical negative, you may argue it
>>>>>> is an
>>>>>> > ugly pattern, but that is largely subjective.
>>>>>>
>>>>>> For what it's worth, I totally agree with Anne that two-prong API is a
>>>>>> huge wart and I feel shame for proposing it. But I would rather feel
>>>>>> shame than waiting for Godot.
>>>>>>
>>>>>> >
>>>>>> > Is this an accurate summary of what we're looking at for possible
>>>>>> solutions?
>>>>>> > If so, can we at least get a decision on whether or not _this_
>>>>>> route is
>>>>>> > acceptable?
>>>>>> >
>>>>>> > FOO_CONSTRUCTOR = document.register(‘x-foo’, {
>>>>>> >   prototype: ELEMENT_PROTOTYPE,
>>>>>> >   lifecycle: {
>>>>>> >      created: CALLBACK
>>>>>> >   }
>>>>>> > });
>>>>>>
>>>>>> I will spec this first.
>>>>>>
>>>>>> >
>>>>>> > FOO_CONSTRUCTOR = document.register(‘x-foo’, {
>>>>>> >   constructor: FOO_CONSTRUCTOR
>>>>>> > });
>>>>>> >
>>>>>>
>>>>>> When we have implementers who can handle it, I'll spec that.
>>>>>>
>>>>>> Eventually, we'll work to deprecate the first approach.
>>>>>>
>>>>>> One thing that Scott suggested recently is that the second API variant
>>>>>> always returns undefined, to better separate the two APIs and their
>>>>>> usage patterns.
>>>>>>
>>>>>> :DG<
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>