In general, only documents associated with a browsing context have non-null custom element registries. Trying to register or create custom elements in other documents, such as those created by createDocument method or a template contents owner document, will fail.
Element registration is a process of adding a custom element definition to a custom element registry.
+ +Because element registration can occur at any time, a non-custom element could be created that might in the future become a custom element after an appropriate definition is registered. Such elements are called undefined potentially-custom elements. If such a definition is ever registered, the element will be upgraded, becoming a custom element.
+ +Each custom element registry has an associated upgrade candidates map tracking undefined potentially-custom elements. Each entry has a key that is a valid custom element name and a value that is a sorted element queue. It is is initially empty.
+To create an element, given a document, localName, prefix, namespace, typeExtension, and optional synchronous custom elements flag, run the following steps:
TypeError exception and abort these steps.TypeError exception and abort these steps.If there is an the entry in registry with name typeExtension, let definition be that entry, and perform the following subsubsteps:
-TypeError exception and abort these steps.is" and type.is" and type.Otherwise:
+ +is" and type.Otherwise, if registry is not null, namespace is the HTML namespace, and registry contains an entry with local name localName:
+Otherwise, if registry is not null, namespace is the HTML namespace, and registry contains an entry with local name localName, let definition be that entry, and perform the following substeps:
If synchronous custom elements flag is set:
@@ -234,6 +256,8 @@This is meant to be a brand check to ensure that the object was allocated by the HTMLElement constructor. Eventually Web IDL may give us a more precise way to do brand checks.
Otherwise:
HTMLElement interface, with no attributes, namespace set to the HTML namespace, namespace prefix set to prefix, local name set to localName, and node document set document.HTMLElement interface, with no attributes, namespace set to the HTML namespace, namespace prefix set to prefix, local name set to localName, defined flag unset, and node document set document.Inside the algorithm for the document.open() method, add a step (near step 18, replacing the Document's singleton objects) that sets the Document's custom element registry to a new empty set.
HTML currently does not do a great job of defining DOM's element interface concept. There is a definition hidden inside the parser, but it isn't explicit that this also covers other element creation cases. We should create a section that is more explicit, and it should roughly contain the following (including the note afterward):
+ +The element interface for an element with name name in the HTML namespace is determined as follows:
+ +HTMLElement.HTMLUnknownElement.
+ The use of HTMLElement instead of HTMLUnknownElement in the case of valid custom element names is done to ensure that any potential future upgrades only cause a linear transition of the element's prototype chain, from HTMLElement to a subclass, instead of a lateral one, from HTMLUnknownElement to an unrelated subclass.
+
The Element interface section will need to be modified as follows. The paragraph listing the values associated with an element should be modified to read as follows, including the note afterward:
Elements have an associated namespace, namespace prefix, local name, and defined flag. When an element is created, all of these values are set. An element whose defined flag is set is said to be defined.
+ ++ As detailed elsewhere in this specification, all elements that are not custom elements are already defined upon their creation. Custom elements become defined once their constructor has been called, either synchronously or during the upgrade process. +
+To enqueue a custom element upgrade, given an element element, run the following steps:
+To enqueue a custom element upgrade, given an element element and custom element definition definition, run the following steps:
This algorithm can only be called when such a definition exists.
-Element registration is a process of adding an custom element definition to a custom element registry.
- -Because element registration can occur at any time, a custom element could be created before its definition is registered. Such custom element instances are called unresolved elements. When an unresolved element is created, and if its element interface was not defined by HTML or other applicable specifications, the unresolved element's element interface MUST be HTMLElement.
HTMLElement as its element interface, rather than HTMLUnknownElement.
-Each custom element registry has an associated upgrade candidates map of all instances of unresolved elements, mapping a valid custom element name to a sorted element queue. It is is initially empty.
- -Whenever an unresolved element is created, it MUST be added to the respective sorted element queue in upgrade candidates map.
- -Elements are upgraded from being unresolved by the upgrade a newly-defined element algorithm.
-Document MethodDocument
-:unresolved Element Pseudo-classThe :unresolved pseudo-class [[!CSS3-SELECTORS]] MUST match all custom elements whose custom element constructor has not yet been invoked.
The :unresolved pseudo-class could be used to mitigate the flash of unstyled content [[FOUC]] issues with custom elements.
-
This can occur if C constructs another instance of the same custom element before calling super(), or if C uses JavaScript's return-override feature to return an arbitrary object from the constructor.
The ':defined' pseudo-class applies to elements that are defined.
+ ++The ':defined' pseudo-class can be used to mitigate the flash of unstyled content [[FOUC]] issues with custom elements. +
+The default semantics of a custom element is dependent upon the form in which it is instantiated: