22899 2013-08-08 02:27:52 +0000 [Custom]: Consider changing the order of custom element upgrade 2013-08-29 22:47:25 +0000 1 1 1 Unclassified WebAppsWG HISTORICAL - Component Model unspecified PC All RESOLVED FIXED P2 normal --- 14968 1 sorvell dglazkov dominicc public-webapps-bugzilla oldest_to_newest 91769 0 sorvell 2013-08-08 02:27:52 +0000 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> 91851 1 sorvell 2013-08-09 21:12:33 +0000 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 91874 2 dominicc 2013-08-12 01:25:36 +0000 What happens if there's a script tag in there? 91947 3 dglazkov 2013-08-12 23:53:38 +0000 (In reply to comment #2) > What happens if there's a script tag in there? DOH. 91948 4 sorvell 2013-08-12 23:56:20 +0000 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 91950 5 dominicc 2013-08-13 00:02:30 +0000 (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> ? 91951 6 dominicc 2013-08-13 00:03:44 +0000 (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> 91961 7 dominicc 2013-08-13 03:39:02 +0000 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. 92081 8 dominicc 2013-08-15 06:16:20 +0000 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. 92717 9 dglazkov 2013-08-29 22:47:25 +0000 https://dvcs.w3.org/hg/webcomponents/rev/a53b6d2507cf