Custom Elements

This page documents open technical issues with Custom Elements based on [email protected] from January to March 2015.

Rough consensus

There appears to be rough consensus for:

• ES6-style classes (Spec/Chrome: mutating prototype)
• Subclassing of HTMLElement and SVGElement
• An API to tie a class to a local name (e.g. registerElement())
• Lifecycle callbacks for: mutation of an attribute

Open issues

• Upgrading
• Lifecycle callbacks
• Subclassing existing elements (is="")
• Using symbols rather than strings

Upgrading

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.

Tactic	Explanation	Drawbacks
Spec/Chrome	A basic element is created by the parser and then its prototype is mutated at a later stage followed by a callback.	Does not use ES6-style classes Does not have identity at all (at best it looks alike due to the mutated prototype)
Brain transplant ("Dmitry")	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.	Not having identity at creation-time is currently a mismatch with the rest of the platform. (Domenic suggests we could maybe change the rest of the platform.)
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.	What about attributes on the dummy element? What about event listeners on the dummy element? What if the dummy element was removed from the tree (or moved around)? Causes mutation observer "spam"
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.	Requires synchronization for document.write() for each custom element. Nested event loop. Does not work with asynchronously loaded assets. Unclear how it works with cloning.
Almost-synchronous constructor ("Jonas")	The parser does bookkeeping of where custom elements need to be inserted and does it at a later synchronization point.	Potential performance issues. Complicated? Unclear how it works with cloning.

(Written under the assumption that mutating the prototype of the basic element is no longer considered viable.)

Lifecycle callbacks

Currently Custom Elements exposes "insertion into a document" and "removal from a document". However, the primitives the DOM exposes are "insert" and "remove".

Subclassing existing elements

Subclassing existing elements is hard as implementation-wise identity is both object-based and name/namespace based. See also DOM: element constructors.

A hack was invented to make this work: <button is="my-button">. This relies on not changing name/namespace. However, this goes against the design goal of custom elements to give web developers control over the markup. And breaks down the moment you want a custom or modified shadow DOM.

To make subclassing of built-in elements work and in general improve built-in elements we need to:

• Figure out built-in elements: https://github.com/domenic/html-as-custom-elements
• Browsers need to change from localName-based checks to crossGlobalIsInstanceOf-based checks (while retaining performance).

This hack did allow for somewhat improved accessibility for trivial components, but that would quickly break down and not scale to anything more complex. It would also provide slightly better integration with the HTML parser. For example, extending <template> for data binding or as a way to specify shadow trees in HTML.

Use symbols to identify lifecycle callbacks

It has been suggested that we should use symbols rather than names ending in Callback to avoid collisions with libraries.

New features (v2)

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). This callback needs to be passed the old and new document.
• Cloning so cloneNode() can have similar semantics for custom elements as it does for e.g. <input>. For cloning we want the browser to create a clone (via the constructor) and copy all content attributes. Then the callback is passed the clone, a document, and the clone children flag (note that these are only needed for children not part of a tree, for elements such as <template>, children part of the tree are handled by the browser).

ARIA integration

https://lists.w3.org/Archives/Public/public-webapps/2014JulSep/0355.html