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

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