In ES6 the constructor does both allocation and initialization. At upgrade time it is too late to do allocation so we cannot call the constructor at that time. We would need a callback for this, call it upgradeCallback for example.
When the parser sees a custom element (any element with a dash in it) it queues a reference to this element without creating a JS wrapper. Before executing a script we need to empty this queue and we can do that by [[Constructing]] the wrappers for these elements, looking up the constructors in the registry. This is similar to how createdCallback is handled today. This means that the constructor can be used if the local name has been registered but that the constructor will not be called for upgrades. User code can structure their code in a way that they can share initialization code. class MyElement extends HTMLElement { constructor() { super(); this.init(); } upgradeCallback() { this.init(); } init() { ... } } document.register('my-element', MyElement); There is also some issues related to the parameters passed to the constructor and it looks like we need to use species for elements created by the parser but I'll let Domenic cover that area. On Mon, Jan 12, 2015 at 12:42 PM, Domenic Denicola <d...@domenic.me> wrote: > From: Tab Atkins Jr. [mailto:jackalm...@gmail.com] > >> Proto munging isn't even that big of a deal. It's the back-end stuff that's >> kinda-proto but doesn't munge that's the problem. This is potentially >> fixable if we can migrate more elements out into JS space. > > It really isn't though, at least, not without a two-stage process like empty > constructor() with [[Construct]] semantics that can never be applied to > upgraded elements + createdCallback() with [[Call]] semantics that can be > applied to upgraded elements after having their __proto__ munged. -- erik