Custom Elements - Revision history

Domenic: Reverted edits by Domenic (talk) to last revision by Annevk

2016-08-01T10:59:10Z

Reverted edits by Domenic (talk) to last revision by Annevk

← Older revision		Revision as of 10:59, 1 August 2016
Line 8:		Line 8:
	* Subclassing of HTMLElement and SVGElement		* Subclassing of HTMLElement and SVGElement
	* An API to tie a class to a local name (e.g. <code>registerElement()</code>)		* An API to tie a class to a local name (e.g. <code>registerElement()</code>)
	* Lifecycle callbacks for: ~~insertion into a document, removal from a document,~~ mutation of an attribute		* Lifecycle callbacks for: mutation of an attribute

	== ~~Additional lifecycle callbacks~~ ==		== Open issues ==

	~~There's a proposal in various bugs to offer these lifecycle callbacks as well:~~		* Upgrading
			* Lifecycle callbacks
	* ~~Adopting so when moving nodes across documents adjustments can be made (e.g. an <code><img></code> has its animation restarted). This callback needs to be passed the old and new document.~~		* Subclassing existing elements (<code>is=""</code>)
	* ~~Cloning so <code>cloneNode~~(~~)</code> can have similar semantics for custom elements as it does for e.g.~~ <code>~~<input></code>. 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 <code><template>~~</code>~~, children part of the tree are handled by the browser~~).		* Using symbols rather than strings

	~~== Use symbols to identify lifecycle callbacks ==~~

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

	== Upgrading ==		=== 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.		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.
Line 68:		Line 64:
	(Written under the assumption that mutating the prototype of the basic element is no longer considered viable.)		(Written under the assumption that mutating the prototype of the basic element is no longer considered viable.)

	== ~~Subclassing existing elements~~ ==		=== Lifecycle callbacks ===

	~~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~~.		Currently Custom Elements exposes "insertion into a document" and "removal from a document". However, the primitives the DOM exposes are "insert" and "remove".

	~~A hack was invented to make this work: <code><button is~~=~~"my-button"></code>. That hack is not well liked leaving us two options:~~		=== Subclassing existing elements ===

	* We leave this for now and ~~work on this in parallel while stabilizing a smaller subset of custom elements~~.		Subclassing existing elements is hard as implementation-wise identity is both object-based and name/namespace based. See also [https://annevankesteren.nl/2015/01/dom-element-constructors DOM: element constructors].
	* We block on this and delay even more.

	However, ~~without~~ this ~~hack accessibility for trivial components is harder as more things have~~ to ~~be done by hand~~.		A hack was invented to make this work: <code><button is="my-button"></code>. 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.

	(~~Assuming~~ that not ~~all implementers are suddenly going~~ to be ~~okay with this hack~~.)		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 <code>localName</code>-based checks to <code>crossGlobalIsInstanceOf</code>-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 <code><template></code> for [https://blog.polymer-project.org/howto/2014/09/11/template-is-autobinding/ data binding] or as a way to specify [http://jsbin.com/xuheb/3/edit?html,output shadow trees in HTML].

			=== Use symbols to identify lifecycle callbacks ===

			It has been suggested that we should use symbols rather than names ending in <code>Callback</code> 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 <code><img></code> has its animation restarted). This callback needs to be passed the old and new document.
			* Cloning so <code>cloneNode()</code> can have similar semantics for custom elements as it does for e.g. <code><input></code>. 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 <code><template></code>, children part of the tree are handled by the browser).

	Another use case had emerged for the "is" hack: piggy-backing on parser behaviors. For example, extending <code><template></code> for [https://blog.polymer-project.org/howto/2014/09/11/template-is-autobinding/ data binding] or as a way to specify [http://jsbin.com/xuheb/3/edit?html,output shadow trees in HTML].		=== ARIA integration ===
	== ARIA integration ==

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

	[[Category:Spec coordination]]		[[Category:Spec coordination]]

Domenic: Reverted edits by Annevk (talk) to last revision by Dglazkov

2016-07-06T12:50:47Z

Reverted edits by Annevk (talk) to last revision by Dglazkov

← Older revision		Revision as of 12:50, 6 July 2016
Line 8:		Line 8:
	* Subclassing of HTMLElement and SVGElement		* Subclassing of HTMLElement and SVGElement
	* An API to tie a class to a local name (e.g. <code>registerElement()</code>)		* An API to tie a class to a local name (e.g. <code>registerElement()</code>)
	* Lifecycle callbacks for: mutation of an attribute		* Lifecycle callbacks for: insertion into a document, removal from a document, mutation of an attribute

	== ~~Open issues~~ ==		== Additional lifecycle callbacks ==

	* Upgrading		There's a proposal in various bugs to offer these lifecycle callbacks as well:
	* ~~Lifecycle callbacks~~
	* ~~Subclassing existing~~ elements (<code>~~is=""~~</code>)		* Adopting so when moving nodes across documents adjustments can be made (e.g. an <code><img></code> has its animation restarted). This callback needs to be passed the old and new document.
	* Using symbols rather than ~~strings~~		* Cloning so <code>cloneNode()</code> can have similar semantics for custom elements as it does for e.g. <code><input></code>. 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 <code><template></code>, children part of the tree are handled by the browser).

			== Use symbols to identify lifecycle callbacks ==

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

	=== Upgrading ===		== 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.		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.
Line 64:		Line 68:
	(Written under the assumption that mutating the prototype of the basic element is no longer considered viable.)		(Written under the assumption that mutating the prototype of the basic element is no longer considered viable.)

	==~~= Lifecycle callbacks =~~==		== Subclassing existing elements ==

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

	=~~== Subclassing existing elements ===~~		A hack was invented to make this work: <code><button is="my-button"></code>. That hack is not well liked leaving us two options:

	~~Subclassing existing~~ elements ~~is hard as implementation-wise identity is both object-based~~ and ~~name/namespace based. See also [https://annevankesteren.nl/2015/01/dom-element-constructors DOM: element constructors]~~.		* 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.

	~~A hack was invented to make this work: <code><button is="my-button"></code>. 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~~.		However, without this hack accessibility for trivial components is harder as more things have to be done by hand.

	~~To make subclassing of built-in elements work and in general improve built-in elements we need to:~~		(Assuming that not all implementers are suddenly going to be okay with this hack.)

	* Figure out built-in elements: https://github.com/domenic/html-as-custom-elements
	* Browsers need to change from <code>localName</code>-based checks to <code>crossGlobalIsInstanceOf</code>-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 <code><template></code> for [https://blog.polymer-project.org/howto/2014/09/11/template-is-autobinding/ data binding] or as a way to specify [http://jsbin.com/xuheb/3/edit?html,output shadow trees in HTML].

	~~=== Use symbols to identify lifecycle callbacks ===~~

	~~It has been suggested that we should use symbols rather than names ending in <code>Callback</code> 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 <code><img></code> has its animation restarted~~)~~. This callback needs to be passed the old and new document.~~
	* Cloning so <code>cloneNode()</code> can have similar semantics for custom elements as it does for e.g. <code><input></code>. 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 <code><template></code>, children part of the tree are handled by the browser).

	=== ARIA integration ===		Another use case had emerged for the "is" hack: piggy-backing on parser behaviors. For example, extending <code><template></code> for [https://blog.polymer-project.org/howto/2014/09/11/template-is-autobinding/ data binding] or as a way to specify [http://jsbin.com/xuheb/3/edit?html,output shadow trees in HTML].
			== ARIA integration ==

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

	[[Category:Spec coordination]]		[[Category:Spec coordination]]

Annevk at 13:05, 6 May 2015

2015-05-06T13:05:09Z

← Older revision		Revision as of 13:05, 6 May 2015
Line 8:		Line 8:
	* Subclassing of HTMLElement and SVGElement		* Subclassing of HTMLElement and SVGElement
	* An API to tie a class to a local name (e.g. <code>registerElement()</code>)		* An API to tie a class to a local name (e.g. <code>registerElement()</code>)
	* Lifecycle callbacks for: ~~insertion into a document, removal from a document,~~ mutation of an attribute		* Lifecycle callbacks for: mutation of an attribute

	== Open issues ==		== Open issues ==

	* Upgrading		* Upgrading
			* Lifecycle callbacks
	* Subclassing existing elements (<code>is=""</code>)		* Subclassing existing elements (<code>is=""</code>)
	* Using symbols rather than strings		* Using symbols rather than strings
Line 62:		Line 63:

	(Written under the assumption that mutating the prototype of the basic element is no longer considered viable.)		(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 ===

Annevk: reorganize (no textual changes)

2015-05-06T12:58:46Z

reorganize (no textual changes)

← Older revision		Revision as of 12:58, 6 May 2015
Line 10:		Line 10:
	* Lifecycle callbacks for: insertion into a document, removal from a document, mutation of an attribute		* Lifecycle callbacks for: insertion into a document, removal from a document, mutation of an attribute

	== ~~Additional lifecycle callbacks~~ ==		== Open issues ==

	~~There's a proposal in various bugs to offer these lifecycle callbacks as well:~~		* Upgrading
			* Subclassing existing elements (<code>is=""</code>)
			* Using symbols rather than strings

	* Adopting so when moving nodes across documents adjustments can be made (e.g. an <code><img></code> has its animation restarted). This callback needs to be passed the old and new document.		=== Upgrading ===
	* Cloning so <code>cloneNode()</code> can have similar semantics for custom elements as it does for e.g. <code><input></code>. 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 <code><template></code>, children part of the tree are handled by the browser).

	== ~~Use symbols to identify lifecycle callbacks ==~~

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

	== ~~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.		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.
Line 68:		Line 63:
	(Written under the assumption that mutating the prototype of the basic element is no longer considered viable.)		(Written under the assumption that mutating the prototype of the basic element is no longer considered viable.)

	== Subclassing existing elements ==		=== Subclassing existing elements ===

	Subclassing existing elements is hard as implementation-wise identity is both object-based and name/namespace based. See also [https://annevankesteren.nl/2015/01/dom-element-constructors DOM: element constructors].		Subclassing existing elements is hard as implementation-wise identity is both object-based and name/namespace based. See also [https://annevankesteren.nl/2015/01/dom-element-constructors DOM: element constructors].
Line 81:		Line 76:
	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 <code><template></code> for [https://blog.polymer-project.org/howto/2014/09/11/template-is-autobinding/ data binding] or as a way to specify [http://jsbin.com/xuheb/3/edit?html,output shadow trees in HTML].		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 <code><template></code> for [https://blog.polymer-project.org/howto/2014/09/11/template-is-autobinding/ data binding] or as a way to specify [http://jsbin.com/xuheb/3/edit?html,output shadow trees in HTML].

	== ARIA integration ==		=== Use symbols to identify lifecycle callbacks ===

			It has been suggested that we should use symbols rather than names ending in <code>Callback</code> 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 <code><img></code> has its animation restarted). This callback needs to be passed the old and new document.
			* Cloning so <code>cloneNode()</code> can have similar semantics for custom elements as it does for e.g. <code><input></code>. 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 <code><template></code>, children part of the tree are handled by the browser).

			=== ARIA integration ===

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

	[[Category:Spec coordination]]		[[Category:Spec coordination]]

Annevk: /* Subclassing existing elements */

2015-04-27T14:14:06Z

Subclassing existing elements

← Older revision		Revision as of 14:14, 27 April 2015
Line 70:		Line 70:
	== Subclassing existing elements ==		== 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~~. See also [https://annevankesteren.nl/2015/01/dom-element-constructors DOM: element constructors].		Subclassing existing elements is hard as implementation-wise identity is both object-based and name/namespace based. See also [https://annevankesteren.nl/2015/01/dom-element-constructors DOM: element constructors].

	A hack was invented to make this work: <code><button is="my-button"></code>. ~~That hack is~~ not ~~well liked leaving us two options:~~		A hack was invented to make this work: <code><button is="my-button"></code>. 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.

	* We leave this for now and ~~work on this~~ in ~~parallel while stabilizing a smaller subset of custom~~ elements.		To make subclassing of built-in elements work and in general improve built-in elements we need to:
	* We block on this and delay even more.

	(~~Assuming that not all implementers are suddenly going to be okay with this hack~~.)		* Figure out built-in elements: https://github.com/domenic/html-as-custom-elements
			* Browsers need to change from <code>localName</code>-based checks to <code>crossGlobalIsInstanceOf</code>-based checks (while retaining performance).

	~~However, without this~~ hack accessibility for trivial components ~~is harder as~~ more ~~things have to be done by hand~~.		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 <code><template></code> for [https://blog.polymer-project.org/howto/2014/09/11/template-is-autobinding/ data binding] or as a way to specify [http://jsbin.com/xuheb/3/edit?html,output shadow trees in HTML].

	~~Another use case had emerged for~~ the ~~"is" hack: piggy-backing on~~ parser ~~behaviors~~. For example, extending <code><template></code> for [https://blog.polymer-project.org/howto/2014/09/11/template-is-autobinding/ data binding] or as a way to specify [http://jsbin.com/xuheb/3/edit?html,output shadow trees in HTML].

	== ARIA integration ==		== ARIA integration ==

Annevk: /* Subclassing existing elements */

2015-03-12T07:27:18Z

Subclassing existing elements

← Older revision		Revision as of 07:27, 12 March 2015
Line 70:		Line 70:
	== Subclassing existing elements ==		== 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.		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. See also [https://annevankesteren.nl/2015/01/dom-element-constructors DOM: element constructors].

	A hack was invented to make this work: <code><button is="my-button"></code>. That hack is not well liked leaving us two options:		A hack was invented to make this work: <code><button is="my-button"></code>. That hack is not well liked leaving us two options:
Line 76:		Line 76:
	* We leave this for now and work on this in parallel while stabilizing a smaller subset of custom elements.		* 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.		* We block on this and delay even more.

			(Assuming that not all implementers are suddenly going to be okay with this hack.)

	However, without this hack accessibility for trivial components is harder as more things have to be done by hand.		However, without this hack accessibility for trivial components is harder as more things have to be done by hand.

	~~(Assuming that not all implementers are suddenly going~~ to ~~be okay with this hack~~.)		Another use case had emerged for the "is" hack: piggy-backing on parser behaviors. For example, extending <code><template></code> for [https://blog.polymer-project.org/howto/2014/09/11/template-is-autobinding/ data binding] or as a way to specify [http://jsbin.com/xuheb/3/edit?html,output shadow trees in HTML].

	Another use case had emerged for the "is" hack: piggy-backing on parser behaviors. For example, extending <code><template></code> for [https://blog.polymer-project.org/howto/2014/09/11/template-is-autobinding/ data binding] or as a way to specify [http://jsbin.com/xuheb/3/edit?html,output shadow trees in HTML].
	== ARIA integration ==		== ARIA integration ==

Dglazkov at 21:06, 11 March 2015

2015-03-11T21:06:02Z

← Older revision		Revision as of 21:06, 11 March 2015
Line 81:		Line 81:
	(Assuming that not all implementers are suddenly going to be okay with this hack.)		(Assuming that not all implementers are suddenly going to be okay with this hack.)

			Another use case had emerged for the "is" hack: piggy-backing on parser behaviors. For example, extending <code><template></code> for [https://blog.polymer-project.org/howto/2014/09/11/template-is-autobinding/ data binding] or as a way to specify [http://jsbin.com/xuheb/3/edit?html,output shadow trees in HTML].
	== ARIA integration ==		== ARIA integration ==

Annevk at 09:01, 5 February 2015

2015-02-05T09:01:42Z

← Older revision		Revision as of 09:01, 5 February 2015
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/ public-webapps@w3.org from January to March 2015].		This page documents open technical issues with [https://w3c.github.io/webcomponents/spec/custom/ Custom Elements] based on [https://lists.w3.org/Archives/Public/public-webapps/2015JanMar/ public-webapps@w3.org from January to March 2015].

	== Rough consensus ==		== Rough consensus ==
Line 7:		Line 7:
	* ES6-style classes (Spec/Chrome: mutating prototype)		* ES6-style classes (Spec/Chrome: mutating prototype)
	* Subclassing of HTMLElement and SVGElement		* Subclassing of HTMLElement and SVGElement
	* ~~registerElement()~~ API to tie a class to a local name		* An API to tie a class to a local name (e.g. <code>registerElement()</code>)
	* Lifecycle callbacks for: insertion into a document, removal from a document, mutation of an attribute		* Lifecycle callbacks for: insertion into a document, removal from a document, mutation of an attribute

Line 56:		Line 56:
	* Nested event loop.		* Nested event loop.
	* Does not work with asynchronously loaded assets.		* Does not work with asynchronously loaded assets.
			* Unclear how it works with cloning.
	\|-		\|-
	! Almost-synchronous constructor ([https://lists.w3.org/Archives/Public/public-webapps/2014JanMar/0098.html "Jonas"])		! Almost-synchronous constructor ([https://lists.w3.org/Archives/Public/public-webapps/2014JanMar/0098.html "Jonas"])
Line 62:		Line 63:
	* Potential performance issues.		* Potential performance issues.
	* Complicated?		* Complicated?
			* Unclear how it works with cloning.
	\|}		\|}

GPHemsley: GPHemsley moved page CustomElements to Custom Elements: Space

2015-02-02T00:31:45Z

GPHemsley moved page CustomElements to Custom Elements: Space

← Older revision	Revision as of 00:31, 2 February 2015
(No difference)

Annevk: /* Subclassing existing elements */

2015-01-16T12:55:25Z

Subclassing existing elements

← Older revision		Revision as of 12:55, 16 January 2015
Line 74:		Line 74:
	* We leave this for now and work on this in parallel while stabilizing a smaller subset of custom elements.		* 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.		* We block on this and delay even more.

			However, without this hack accessibility for trivial components is harder as more things have to be done by hand.

	(Assuming that not all implementers are suddenly going to be okay with this hack.)		(Assuming that not all implementers are suddenly going to be okay with this hack.)