w3c/webcomponents

This reverts commit 750542c.

See d95392f#commitcomment-16980405. The spec that reflects implementer consensus is still viewable at https://rawgit.com/w3c/webcomponents/15a203c8393aef0df7223ab1d43406aa11a7e71e/spec/custom/index.html, but that text was not produced under the proper process and so is not a product of the working group.

It was doing basically the same thing, just in a more error-prone way.

Fixes #454.

Fixes #461, and adds some nice examples.

This changes the model for "create an element" fairly extensively. The goal is to be more consistent about handling type extensions, in a few ways.

The main observable differences after this change are:

- Edge cases where is="" "doesn't work" now just treat it as a normal attribute, instead of throwing or creating HTMLUnknownElement. (Examples of such cases are given in #466 (comment))
- While the constructor for a type extension is running, the is="" attribute is not present.
- A NotFoundError is thrown if createElement(NS) is passed a { is: ... } value that does not correspond to an existing custom element definition (fixes #466).
- Upgrades of type extensions during parsing and createElement(NS) are now sync (fixes #469).

In terms of spec factoring:

- A new algorithm, "look up a custom element definition", allows figuring out if a given (document, namespace, localName, is) tuple corresponds to a custom element definition
- This new algorithm is used in various places to figure out whether the result of "create an element" will be a custom element.
- Setting the is="" attribute is no longer done by "create an element"; instead, it is treated like other attributes during cloning, parsing, etc.

Since custom element registries are no longer associated with documents, this doesn't make much sense. Instead we will just throw when you try to use uppercase letters, since uppercase letters are not valid custom element names. This fixes #471 since we no longer need a reference to the document.

Also, switch variable names from action(s) to reaction(s).

All usages are in sections that will upstream into HTML, which prefers the term "authors."

As explained in that bug, the discussion of the "previous" state is not necessary and is a bit confusing.

It is now "drawbacks of custom tags".

While doing so, rewrite it to show a full custom element definition, instead of some serialization of the in-DOM markup using inline event handlers.

Fixes #349.

No content change. Moved custom element reactions under the main custom elements section; consolidated the patches in "Instantiating custom elements" into "Miscellaneous patches"; and rearranged so that HTML patches come first, then DOM patches.

Now that I understand the stack-of-queues structure better, it's clear that the way to do this is to push a new queue onto the stack.

See #458 for some discussion.

Add warnings on known issues, and move the "current element queue" definition around.

The spec previously had a NOTE claiming that the algorithm was never called in such cases, but that was false. Instead, just bail if there's no browsing context.

Per #457, it is used for async parsing/construction, but the spec no longer has that. So currently it's not possible for the base element queue to ever be used.

Awesomely, this takes along the concepts "sorted element queue", "custom element order", "processing base element queue", and "processing base element queue flag".

Introduces the new term, "custom element reactions", since upgrades do not call a callback but instead use the constructor. Use the "reaction" terminology throughout. Makes the "lifecycle callbacks" definition a bit clearer. Also adds some introductory paragraphs explaining the motivation; this closes #368.

connectedCallback was being called twice when inserting an element upgraded it.

The new example illustrates the conclusion we came to in #419.

Also update to new "in a shadow-including document" terminology.

Link to the section when talking about the general concept, and to the algorithm only when specifically referencing the algorithm. This makes the dfn.js popup on "upgrade an element" significantly more useful.

PR: #456

In particular, now that w3c/respec#582 is fixed, we don't need to define "konstructor" anymore.