[Bug 22899] New: [Custom]: Consider changing the order of custom element upgrade

https://www.w3.org/Bugs/Public/show_bug.cgi?id=22899

            Bug ID: 22899
           Summary: [Custom]: Consider changing the order of custom
                    element upgrade
    Classification: Unclassified
           Product: WebAppsWG
           Version: unspecified
          Hardware: PC
                OS: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Component Model
          Assignee: dglazkov@chromium.org
          Reporter: sorvell@chromium.org
        QA Contact: public-webapps-bugzilla@w3.org
            Blocks: 14968

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>

-- 
You are receiving this mail because:
You are the QA Contact for the bug.

Received on Thursday, 8 August 2013 02:27:55 UTC