Fwd: XBL2: First Thoughts and Use Cases

On Tue, Dec 14, 2010 at 10:32 PM, Boris Zbarsky <bzbarsky@mit.edu> wrote:
> On 12/14/10 10:08 PM, Tab Atkins Jr. wrote:
>>
>> Hm, good point.  So then, no, there has to be an element in the shadow
>> DOM that represents an output port, which is then *replaced* with the
>> appropriate normal-DOM children in the final flattened tree.
>
> So just to make sure we're on the same page... are you thinking in terms of
> there being separate DOM nodes in the template, in the shadow DOM and in the
> final flattened tree?

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.

(Events and such don't work on the final flattened tree, they work on
the DOM augmented with shadow DOMs, in such a way that the existence
of shadow DOMs isn't revealed to elements that don't need to know
about them.)


>>> <content>
>>>  <div>
>>>    <span></span>
>>>    <children/>
>>>    <span></span>
>>>  </div>
>>> <content>
>>>
>>> And then you remove the first span.
>
> So that in this case there would be a span element in the shadow DOM and a
> different span element in the flattened tree?

Subject to what I said above, maybe?


>> 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.


>> ...exactly as expected, since you're just mutating a DOM, and output
>> ports are real DOM nodes.
>
> 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.  The shadow doesn't directly
know whether its output port has any normal-DOM elements associated
with it, or how many, though this is something you should be able to
easily query with script (possibly a property on the output port
returning a NodeList of normal-DOM elements associated with it).


>>> The way Gecko's implementation "works" if one can call it that is that
>>> there
>>> is the template DOM and then the shadow DOM.  The shadow DOM is created
>>> by
>>> cloning the template DOM, more or less.  Output ports are kept track of
>>> on
>>> the template DOM.  When you insert a node as a child under the bind
>>> element,
>>> you find the right port in the template DOM, then try to find the
>>> corresponding location in the (possibly mutated) shadow DOM.  This
>>> clearly
>>> doesn't work very well!
>>
>> Ah, so it *is* an issue with combining mutable shadows with live
>> templates!
>
> 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.

~TJ

Received on Wednesday, 15 December 2010 15:52:34 UTC