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

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