Re: XBL2: First Thoughts and Use Cases

On Tue, Dec 14, 2010 at 9:34 PM, Boris Zbarsky <bzbarsky@mit.edu> wrote:
> On 12/14/10 4:50 PM, Tab Atkins Jr. wrote:
>>
>> I wasn't thinking of positioning the port with respect to explicit
>> shadow children.  That sounds like something that could be simplified
>> by punting - change the template language so that you can only set
>> output ports on childless elements (use a void element for output
>> ports in the template, which becomes an empty container in the
>> shadow?)
>
> That ends up creating extra elements, right?  The common use cases I've seen
> do in fact have the port as a child of an element with explicit shadow
> children.
>
> Note that with flexbox layout having to insert an element like that means
> that some layouts become impossible.

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.


>>> 4.  Nodes are added or removed from the DOM which affect the position of
>>> a
>>> particular output port in its parent node.
>>
>> I'm not sure I understand.  Can you elaborate with a trivial example?
>> I've got a few things in mind that you could possible mean, but I'd
>> rather not guess.
>
> Using XBL1 syntax, because I can't recall what the XBL2 one is off the top
> of my head:
>
> <content>
>  <div>
>    <span></span>
>    <children/>
>    <span></span>
>  </div>
> <content>
>
> And then you remove the first span.

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>

...exactly as expected, since you're just mutating a DOM, and output
ports are real DOM nodes.


>>> Gecko doesn't have live templates; just mutable shadows.
>>
>> Okay.  So you do something similar to what I've described with
>> instantiating the template into data structures, just limited to the
>> C++ side of the code?
>
> I'm not sure what you mean by "limited to the C++ side of the code".

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


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

Yeah, the way XBL1 does it is clearly wrong if you allow mutating
shadow.  A much saner way is to just make the output ports be real
elements in the shadow DOM, like I outline above.

~TJ

Received on Wednesday, 15 December 2010 06:09:30 UTC