[Bug 21485] New: [Custom]: Consider possible candidates of element upgrade

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

            Bug ID: 21485
           Summary: [Custom]: Consider possible candidates of 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: morrita@google.com
        QA Contact: public-webapps-bugzilla@w3.org
            Blocks: 14968

TL;DR:
Current upgrade algorithm isn't perfect
but better than possible alternatives in my mind.

Moved discussion from [1].
Current upgrade algorithm [2] does the upgrade only in-document elements.
This means that any out-of-document element which has becomes-valid name
doesn't get upgraded. For example:

  var outOfDocElement = document.createElement("x-foo");
  document.register("x-foo", ...);
  // a) Here |outOfDocElement| doesn't get any upgrade.
  document.body.appendChild(outOfDocElement);
  // b) It won't be upgraded even after inserted into document.

This might be confusing and inconvenient for developers so
it's worth exploring better approach.

Here are three alternative approaches:

- A: Upgrade all elements regardless they are in the document.
- B: Current algorithm +
     Upgrade "yet-to-be-upgraded" elements when it is inserted into the
document.
- C: Current algorithm +
     Provide document.upgrade(element) API for explicit upgrade.

Approach A might be straightforward from developers' perspective.
However, it requires implementations to track all unresolved elements, which is
bad IMO. 

How about B? It seems natural extension of A.
B raises an interesting question though: What does happen when a custom
element,
which lives in a document D1, is inserted to different document D2,
which has different custom element definition on same element name?

Should the element be "upgraded" to D2's definition? Or should it stay D1's
definition?
I think this complication comes from the idea to tie the element definition and
document closures.

C just exposes the upgrade algorithm to developers and let them handle it in
the way they want.
This might just work. But I feel it a premature fine-tuning and want to let us
go without it
and see what developers find.

In summary, each alternative has its own caveats and current behavior is the
best preferable
due to its simplicity.

----
[1] https://bugs.webkit.org/show_bug.cgi?id=113362
[2]
https://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/custom/index.html#dfn-element-upgrade

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

Received on Monday, 1 April 2013 06:21:56 UTC