This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Classes in ES6 have class side inheritance. DOM in Firefox and WebKit also have class side inheritance. Custom element constructor does not yet have class side inheritance. class B extends HTMLElement {} B = document.register('x-b', B); assert(B.__proto__ === HTMLElement); class C extends B {} C = document.register('x-c', C); assert(C.__proto__ === B);
Correction to previous post: s/WebKit/Blink/ old habits die hard
FWIW, this is experimentally implemented in Blink. The way the constructor is discovered is simply dereferencing the 'constructor' property on the provided prototype. Prototype lookup does the rest. This happens right after the prototype is retrieved from the options object. The retrieved value isn't scrutinized. If retrieving the constructor destroys the world, we throw an invalid context exception later (similar to the what happens if retrieving the prototype from the options destroys the world.) Of course, I'm open to changing any and all of these details. This is just the first cut to get feedback from developers.
Custom Elements spec just says "Let CONSTRUCTOR be the interface object whose interface prototype object is PROTOTYPE", fully relying on WebIDL properly defining what this means (including class-side inheritance). From what I could glean, http://dev.w3.org/2006/webapi/WebIDL/#dfn-interface-object does not specify class-side inheritance. Should it?
FWIW, the change that implemented constructor-side inheritance experimentally in Blink was rolled out.