You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
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.
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.
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.
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
https://w3c.github.io/webcomponents/spec/custom/#dfn-sorted-element-queue
The text was updated successfully, but these errors were encountered: