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 Brainstorming

From WHATWG Wiki
Revision as of 16:45, 21 December 2010 by Dglazkov (talk | contribs) (→‎Strawman 1)
Jump to navigation Jump to search

These are just some free-style thoughts at the moment.

Strawman 1

  • Templates behave like stencils. Once an instance is created, there's no perceptible connection between the template and the instance.
    • The instance is the shadow subtree on the bound element.
  • The associated metadata (attribute forwarding, pseudo, output ports) stays with the shadow subtree.
    • There may be "copy-on-write"-style optimization possibilities.
  • The metadata is expressed as rules, where each rule describes how DOM information is relayed from bound element to the shadow subtree
    • Each rule has a condition, associated with it.
    • Node rules describe how the children of the bound element are presented in the shadow subtree.
      • Node rule conditions are expressed as collapsed ranges (insertion points). Even better, it's a boundary point
      • Any time a node is added to the bound element, the condition for each rules is evaluated sequentially against this node until the match is found.
      • The same happens when the bound element is attached to the document.
        • If no match is found, the node is considered to be "twilight" and does not render (same behavior as appending a DOM node to an input element).
      • Mutations of the shadow subtree may invalidate node rules
        • For example, the elements anchoring the insertion point (parent, next or previous sibling) are moved.
        • The validity of the insertion point is determined only when the rules are evaluated.
      • There may be some guarantees of stability around insertion points and shadow subtree mutation.