Component Model Brainstorming

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

Hitchhiker's Guide Strawman

• Every element has a shadow property. This property expect a DOM node.
  • The subtree of this node becomes element's shadow subtree upon setting the shadow property.
• Every element has an output property. This property can be set to:
  • null or any element not in the document tree, which makes all direct children of an element not render
  • a sub-element in shadow subtree, which makes all direct children of an element render as children of that sub-element
  • the element itself, which makes all direct children render as they would without a shadow subtree.
    • the shadow subtree is rendered as if its root is the additional first (or last?) direct child of the element.
• In CSS, you can address elements inside of the shadow by using ::shadow pseudo-attribute, which directs selector into the shadow tree.
  • For example, div.foo::shadow p will match all paragraph elements inside of the shadow tree, assigned to div.foo.
• That's it. There is no templating, no multiple output ports, no forwarding, no nothing. It's bare minimum and meant to be that way.

Attack of the Clones Strawman

• 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.
• Binding metadata is part of the shadow subtree, where metadata is attribute forwarding, pseudo, output ports, etc.
  • 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

• 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: Changing this attribute results in node redistribution, which is not the case for this strawman (see Dynamicity of Rules use case).