Custom elements' upgrade order is ambiguous in the case of a detached node

[rniwa]

When a custom element is created but not in any document tree or its shadow-inclusive descendants, the order in which those elements are upgraded is not well defined with the following definition:

https://w3c.github.io/webcomponents/spec/custom/#dfn-upgrade-candidates-map

Each registry has an associated upgrade candidates map of all instances of unresolved elements, mapping a custom element type to a sorted element queue. It is is initially empty.

https://w3c.github.io/webcomponents/spec/custom/#dfn-sorted-element-queue

In addition to an element queue, there is also a sorted element queue. The custom elements are kept in the order of increasing custom element order.

[rniwa]

Also see the issue #419. Perhaps elements detached from a document is not supposed to be upgraded?

Now, I would really prefer upgrading custom elements in the order they were instantiated by the DOM API / HTML parser because that would avoid a rather expensive O(n) operation to figure out the relative ordering of each custom element at the time defineElement is called.

Given that the number of an upgradable element of a particular name is probably much smaller than the total number of elements in a page, this approach is less than ideal.

[domenic]

Now, I would really prefer upgrading custom elements in the order they were instantiated by the DOM API / HTML parser

I think that is the intent of the spec's "document custom element order" concept. However, it would be better if this were an explicit list tracked by the parser and createElement.

[domenic]

I guess this will be solved as part of #424.

[domenic]

I believe this is explicit now, given https://w3c.github.io/webcomponents/spec/custom/#dfn-create-element is clear about when it enqueues a custom element upgrade or it enqueues the element in the appropriate upgrade queue. However, there is still #419 to resolve.