Re: XBL2: First Thoughts and Use Cases

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?

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

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

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

> I just mean that the output ports and other things are kept track of
> by the browser, but aren't exposed to JS directly.

Yes.

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

-Boris

Received on Wednesday, 15 December 2010 06:32:35 UTC