Re: Minimum viable custom elements

> On Jan 15, 2015, at 3:17 PM, Domenic Denicola <d@domenic.me> wrote:
> 
> From: Ryosuke Niwa [mailto:rniwa@apple.com] 
> 
>> If ES6 classes' constructor doesn't fundamentally work with custom elements, then why don't we change the design of ES6 classes.
> 
> We would essentially be saying that the design of ES6 classes should be built to support one particular construction pattern (two-stage construction), over any others. Why not design it to support three-stage construction? There are surely libraries that have more than two phases of boot-up.
> 
> One way to think about it is that there is a "base constructor" for all classes (corresponding, in spec language, to the definition of [[Construct]]), that in the newest TC39 design does the simplest thing possible. The DOM needs a more complicated setup. Shouldn't that be the DOM's responsibility to encode into *its* base constructor?

No, DOM doesn't require two-stage construction any more than a regular builtin objects in ES6.

The only reason you need to have the two-stage setup is because you want to support asynchronous upgrading of elements.  As we have repeatedly stated in the past, we don't support a design that involves upgrading elements after the element construction if it meant that we can't use ES6 constructor in the non-upgrade case.  We'll submit a formal objection if necessary.

>> Saying that TC39 doesn't have a time is like saying we can't make a spec change because WG has already decided to move the spec into REC by the end of the year in W3C.
> 
> That, I certainly agree with. Any process reasons brought up are bogus. But the technical arguments for "the simplest base constructor possible" in the language are pretty sound. They're in fact reasons that motivated TC39 to go into a last-minute redesign marathon over the holiday weeks, to get *away* from the more complicated "base constructor" that contained a two-stage allocation/initialization split.


That's fine.  And I'm suggesting to do the same (picking the simplest design) in HTML custom elements by only supporting synchronous definition of elements, and letting authors and frameworks decide how to "upgrade" existing elements if they want to.

- R. Niwa

Received on Friday, 16 January 2015 01:30:01 UTC