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: Difference between revisions
Jump to navigation
Jump to search
| Line 10: | Line 10: | ||
** the element itself, which makes all direct children render as they would without a shadow subtree. | ** 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. | *** 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. | * '''In CSS, you can address elements inside of the shadow by using ::shadow pseudo-attribute''', which directs selector into the shadow tree. | ||
** For example, <code>div.foo::shadow p</code> will match all paragraph elements inside of the shadow tree, assigned to <code>div.foo</code>. | ** For example, <code>div.foo::shadow p</code> will match all paragraph elements inside of the shadow tree, assigned to <code>div.foo</code>. | ||
Revision as of 21:37, 22 December 2010
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
shadowproperty.
- The subtree of this node becomes element's shadow subtree upon setting the
- Every element has an output property. This property can be set to:
nullor 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 pwill match all paragraph elements inside of the shadow tree, assigned todiv.foo.
- For example,
- 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: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.