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

Nope, you're 100% right, I saw *header *and thought HTML*Heading*Element
for some reason - so this seems like a valid concern. What are the
mitigation/solution options we can present to developers for this case?


Daniel J. Buchner
Product Manager, Developer Ecosystem
Mozilla Corporation


On Tue, Feb 19, 2013 at 9:17 PM, Scott Miles <sjmiles@google.com> wrote:

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