There appears to be rough consensus for:
- ES6-style classes
- Subclassing of HTMLElement and SVGElement
- registerElement() API to tie a class to a local name
- Lifecycle callbacks for: insertion into a document, removal from a document, mutation of an attribute
Additional lifecycle callbacks
There's a proposal in various bugs to offer these lifecycle callbacks as well:
- Adopting so when moving nodes across documents adjustments can be made (e.g. an
<img>has its animation restarted)
- Cloning so
cloneNode()can have similar semantics for custom elements as it does for e.g.
Upgrading is the concept of going from a piece of markup, such as
<my-div data-teehee="💩"></my-div>, to an object in a tree.
|Brain transplant||A basic element is created by the parser and a callback registered by the developer is invoked at a later point to turn that basic element into a custom element.||
|Dummy replacement||A dummy element is created by the parser and replaced at a later point by an actual instance of the custom element created by invoking the constructor registered by the developer.||
|Synchronous constructor||The constructor registered by the developer is invoked by the parser at the point the custom element is created and inserted into the tree.||
(Written under the assumption that mutating the prototype of the basic element is no longer considered viable.)
Subclassing existing elements
Subclassing existing elements is hard as implementation-wise identity is both object-based and name / namespace based. Therefore subclassing an existing element (currently) requires that the name / namespace does not change.
A hack was invented to make this work:
<button is="my-button">. That hack is not well liked leaving us two options:
- We leave this for now and work on this in parallel while stabilizing a smaller subset of custom elements.
- We block on this and delay even more.
(Assuming that not all implementers are suddenly going to be okay with this hack.)