On 12/15/10 7:51 AM, Tab Atkins Jr. wrote:
Yes to the first two. Maybe to the last - the final flattened tree is
just what's handed to CSS as the element-tree. There aren't "really"
DOM nodes there, or at least it doesn't matter whether or not there
is.
OK.
(Events and such don't work on the final flattened tree
Sort of. Hit testing clearly needs to work on the layout structure
generated from the final flattened tree, so event target determination
works on the flattened tree, while event propagation works on the shadow
DOMs.
What worries me is that if we bake this conceptual assumption about the
shadow DOM nodes being distinct from the flattened tree elements that
gives us the freedom to write a spec that in fact requires both to be
represented by distinct objects, increasing the memory and complexity
needed to implement. More on this below.
Ah, ok. Given what I said above (shadow node representing the port,
which is replaced in the final flattened tree), then this is trivial.
Removing the first span would just change the shadow to be:
<div>
<outputport>
<span></span>
</div>
OK; how would it change the flattened tree? Or am I misunderstanding your
conceptual model?
The final flattened tree wouldn't have the first original first span,
since it's not in the DOM anymore. It would just look like:
<div>
...any normal-DOM elements associated with the output port...
<span></span>
</div>
Hopefully this is the obvious answer.
Well... it's the desired answer. It wasn't obvious from your
formulation, no.
Should they be, though? Should .childNodes.length on the parent of an
output port in the flattened tree count the output port?
Sure - from the perspective of the shadow node, it has some shadow
children, which may include output ports.
So should the output port nodes then be exposed to methods manipulating
the shadow DOM? Should it be ok to move output ports around in the
shadow tree? If so, why?
My preference, fwiw, would be that output ports are not present as DOM
nodes in the shadow DOM. That significantly reduces the complexity of
specifying the behavior, I think....
No. The template is not "live" in the sense that it never mutates. It's a
completely static DOM.
Oh, gotcha. Well, still, the problem arises from the (cloned)
template DOM and the shadow DOM being separate things that can drift
out of sync. That's not what happens in our idea - the shadow is
cloned from the template, and then it's the only source of truth.
So here's the thing. XBL1 was originally designed as a reusable
component model with the idea that the components would actually be
reused, with possibly many (tens of thousands) of instantiations of a
given template. Which means that memory usage for each instantiation is
a concern, which is why as much as possible is delegated to the shared
state in the template.
At least in Gecko's case, we still use XBL1 in this way, and those
design goals would apply to XBL2 from our point of view. It sounds like
you have entirely different design goals, right?
-Boris
