Re: Minimum viable custom elements

> On Jan 15, 2015, at 11:28 AM, Domenic Denicola <d@domenic.me> wrote:
> 
> From: Dimitri Glazkov [mailto:dglazkov@google.com] 
> 
>> Why is "Not having identity at creation-time is currently a mismatch with the rest of the platform" a problem? Why does it all have to be consistent across the board? Are there any other platform objects that are created by HTML parser or a similar device?
> 
> In IRC we've been discussing how I don't think there's actually any (observable) mismatch with the rest of the platform if we are careful.
> 
> In particular, if we make it a rule that when parsing a given fragment, createdCallbacks run in registration order (not, say, in parse order), I think it works. Because then the built-in elements, which are (conceptually) registered first, go through the __proto__-munge + createdCallback() process first. Then, when the createdCallback() for any user-defined elements runs, all existing elements look to be already upgraded.
> 
> If we want createdCallbacks to run in parse order (which does seem probably better, although I'd be curious for concrete arguments why), then the only deviation required between custom and built-in elements is privileging the native elements with some ability to jump to the front the queue. Which seems pretty reasonable given that we already have lots of cases where custom elements do things sorta-async and native elements need to do things more synchronously.

Let's think about this for a minute.

Imagine that a hypothetical technology company Durian which has a popular platform called dOS with its own UI framework called Odour coupled with a programming language named Stink.  In their exciting annual developer conference of the year, Durian introduces Stink 2.0 which supports proper OOP as well as a way to subclass a view in Odour.  Developers rejoice for finally being able to use constructors, inheritance, etc… and subclass views in their applications.  Unfortunately for developers, native syntax for inheritance in Stink 2.0 cannot be used to subclass views in Odour.  In order to inherit from a view in Odour, Durian explains, developers must use a helper function.  Developers outrage in despair and yells, "why on the earth did you have to make them incompatible?"

I ask the same question.  If ES6 classes' constructor doesn't fundamentally work with custom elements, then why don't we change the design of ES6 classes.  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.  We shouldn't be making technical decisions like that especially for something as fundamental as supporting classes in the Web.

- R. Niwa

Received on Thursday, 15 January 2015 22:54:12 UTC