> On Jan 16, 2015, at 9:58 AM, Anne van Kesteren <ann...@annevk.nl> wrote: > > On Fri, Jan 16, 2015 at 2:29 AM, Ryosuke Niwa <rn...@apple.com> wrote: >> 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. > > That seems to put us at an impasse. I get the impression this scenario > is important to Google and their two-stage constructor design > addresses it. To convince them it sounds like they need to see at > least a plausible strategy for custom elements v2 that addresses this.
I get that. However, nobody has suggested a design that satisfies both of our requirements: using ES6 constructor for element initialization while supporting asynchronous definitions of custom elements. > At which point we're back to something like "dummy replacement" with > its problems. Or perhaps something like "HTML modules", where you > import a whole swath of (custom) elements at once. Or we could simply set the prototype. That has a bunch of problems we've discussed but given that's what Google has spec'ed and shipped in their browser, I have a hard time believing that it would be an issue for them. So we could simply do that if such an approach proves to be popular among developers. We can simply add something like "upgraded" callback for that purpose. In other words, use ES6 constructor for custom element creations within the parser and for "new MyCustomElement" and provide a separate lifecycle callback if the author chooses to "upgrade" existing elements that are already in the document. - R. Niwa
