This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
The spec says "Whenever an unresolved element is created, it must be added at the front of the upgrade candidates map." The resulting behavior for a dom tree like the following is that the createdCallbacks are called in reverse order: <x-a> 4 <x-a-1> 3 </x-a> <x-b> 2 <x-b-1> 1 </x-b> This allows an element's children to be upgraded before itself. This is *desirable* since can allow a parent to act on its children in their upgraded state during its created callback. However, it's *undesirable* for <x-b> (older sibling) to upgrade before <x-a> (younger sibling). Imagine for example, the <element> tag implemented as a custom element. It's logical to write the extendee html before the extendor. However, if younger sibling is upgraded first, there's a problem: <el-ement name="x-foo">... </el-ement> 2 <el-ement name="x-bar" extends="x-foo">... </el-ement> 1 It's most important to preserve sibling order. Secondarily, ideally children go before parents. Putting those together, we get: <x-a> 2 <x-a-1> 1 </x-a> <x-b> 4 <x-b-1> 3 </x-b>
If the notion is that elements queue themselves for upgrade when their end tag is encountered, then the flow of upgrade is logically `forward` and preserves the children upgrade before parents preference: <x-a> <x-a-1></x-a-1> 1 </x-a> 2 <x-b> <x-b-1></x-b-1> 3 </x-b> 4
What happens if there's a script tag in there?
(In reply to comment #2) > What happens if there's a script tag in there? DOH.
I don't think this needs to change the behavior of scripts. If we 'go' at the end tag, this seems to fit nicely: <x-a> <x-a-1><script></script></x-a-1> 1 <script></script> </x-a> 2 <script></script> <x-b> <x-b-1></x-b-1> 3 </x-b> 4
(In reply to comment #4) > I don't think this needs to change the behavior of scripts. If we 'go' at > the end tag, this seems to fit nicely: > > <x-a> > <x-a-1><script></script></x-a-1> 1 > <script></script> > </x-a> 2 > <script></script> > <x-b> > <x-b-1></x-b-1> 3 > </x-b> 4 Upgrading one of these means running script (createdCallback) or at least having script-visible effects (prototype). So we need to number the script tags too. So you mean this should be: 4 <x-a> <x-a-1> 1 <script></script> 2 </x-a-1> 3 <script></script> </x-a> 5 <script></script> 7 <x-b> 6 <x-b-1></x-b-1> </x-b> ?
(In reply to comment #5) Oops, I labelled a close tag. I meant: 4 <x-a> 2 <x-a-1> 1 <script></script> </x-a-1> 3 <script></script> </x-a> 5 <script></script> 7 <x-b> 6 <x-b-1></x-b-1> </x-b>
In thinking about this more, the part of the spec that talks about prepending the callback queue for a created element to the element queue should change. I think this is an opportunity to make things simpler and more regular; the created callback should simply be enqueued like any other.
Custom Elements is now implemented this way in Blink. An additional detail I'm not sure we covered explicitly: Upgrade from post-hoc registration happens in the order it would have happened if the definition was available beforehand.
https://dvcs.w3.org/hg/webcomponents/rev/a53b6d2507cf