A user account is required in order to edit this wiki, but we've had to disable public user registrations due to spam.

To request an account, ask an autoconfirmed user on Chat (such as one of these permanent autoconfirmed members).

Custom Elements: Difference between revisions

From WHATWG Wiki
Jump to navigation Jump to search
(Created page with "== Upgrading == Upgrading is the concept of going from a piece of markup, such as <code><my-div data-teehee="💩"></my-div></code>, to an object in a tree. {| class="...")
 
Line 1: Line 1:
This page documents some of the discussion about [https://w3c.github.io/webcomponents/spec/custom/ Custom Elements] in [https://lists.w3.org/Archives/Public/public-webapps/2015JanMar/ [email protected] from January to March 2015].
== Rough consensus ==
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 <code>&lt;img></code> has its animation restarted)
* Cloning so <code>cloneNode()</code> can have similar semantics for custom elements as it does for e.g. <code>&lt;input></code>
== Upgrading ==
== Upgrading ==


Line 30: Line 48:
|-
|-
|}
|}
(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: <code>&lt;button is="my-button"></code>. 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.)

Revision as of 10:10, 15 January 2015

This page documents some of the discussion about Custom Elements in [email protected] from January to March 2015.

Rough consensus

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. <input>

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
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.
  • Not having identity at creation-time is a giant mismatch with 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.

(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.)