Component Model Brainstorming

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.

Problems with strawman:

• Trapped light nodes: if light node distribution in shadow subtree is rule based, you can have a situation when the node is distributed to an insertion point by a rule, then the rule changes or is invalidated by a subtree mutation, the node remains in its position, but no longer has any matching rules. How big of a problem is this?
• Reflow surprises: Similar to trapped light nodes, once the rules and the actual distribution don't match, re-flattening the shadow subtree will produce a different result. For instance, in WebKit, render tree will hold the flattened subtree. If the scripts flips to {{{display:none}}} and back on the bound element, the render tree will be destroyed and rebuilt, which will cause the node rules to be re-applied and thus change the position of the light nodes.
  • There may be a need for some guarantees of stability around insertion points and shadow subtree mutation.
• Non-dynamic rules: As XBL2 spec'd today, the includes attribute is fully dynamic. That is, changing this attribute results in node redistribution, which is not the case for this strawman.