A user account is required in order to edit this wiki, but we've had to disable public user registrations due to spam.

To request an account, ask an autoconfirmed user on Chat (such as one of these permanent autoconfirmed members).

Component Model Progressive Enhancement

From WHATWG Wiki
Revision as of 00:37, 29 October 2011 by Rolandsteiner (talk | contribs)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

A. While adding an element to a DOM tree:

  1. Check for existence of the becomes attribute. If the attribute exists:
    1. Check the value of the becomes attribute against the names of already defined elements.
      1. If such element exists, go to step X.
      2. Otherwise, store a reference to this instance in a "may-become" table.

B. When a new element is registered:

  1. Check to see if there are any instances waiting in the "may-become" table for this element's name
  2. If so, collect all these instances and, for each instance, go to step X.

C. When the "becomes" attribute is set:

  1. If the element is in tree, go to step A 1.1.

X. Becoming another element (in Element existing instance).

  1. Create the element by the name, specified in the becomes attribute of the existing instance
  2. If the existing instance is already in document tree:
    1. execute renameNode (or something better) to replace the old element with the newly created element.
    2. Otherwise, insert newly create element in DOM tree.
  3. Fire "become" event on the existing instance.
  4. Set became property on the existing instance to point to the newly created element.

RolandSteiner Does this mean an author may need to duplicate CSS selectors, e.g., if we have <div becomes="x-foo" class="c"> and a selector div.c, don't we then also need an equivalent selector x-foo.c? OTOH, is it a problem? Perhaps more so in JS with querySelectorAll than in CSS?