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
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.
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:noneand 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. Being able to control node distribution from outside of the shadow subtree seems like a useful feature. Consider this example:
<html>
<head>
<binding element="ul.news">
<template>
<h2>Breaking News</h2>
<ul id="breaking">
<content includes="li.breaking"></content>
</ul>
<h2>Other News</h2>
<ul id="other">
<content></content>
</ul>
</template>
</binding>
</head>
<body>
<ul class="news">
<li class="breaking">Santa seen crossing Atlantic</li>
<li>Pies pose serious health risk, scientists say</li>
</ul>
</body>
</html>
Here, the importance of the news item is controlled outside of the shadow subtree. By setting/removing class breaking on a news item, the consumer of the binding can move it in and out of the breaking news section. Implementing this without dynamic rules seems cumbersome and non-trivial.