Re: Fwd: XBL2: First Thoughts and Use Cases

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

Received on Wednesday, 15 December 2010 18:20:02 UTC