Re: XBL2: First Thoughts and Use Cases

On Tue, Dec 14, 2010 at 4:25 PM, Boris Zbarsky <bzbarsky@mit.edu> wrote:
> On 12/14/10 11:40 AM, Tab Atkins Jr. wrote:
>>
>> Hmm.  I'm not well-versed enough in XBL1 to understand what all the
>> difficulties are, but what we're envisioning is pretty simple and
>> shouldn't lead to many problems.
>>
>> Given a template with some output ports, it's instantiated by cloning
>> the shadow DOM and then setting up a map of selectors->shadow-nodes to
>> represent the output ports.
>
> A single shadow node can have multiple output ports under it, right? And you
> have to keep track of the positions of those output ports in the child list
> of that shadow node (something the XBL1 implementation in Mozilla fails to
> do very well, say).  And nothing actually precludes multiple ports sharing
> the same selector (more on this below).

Multiple output ports, yes.

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?), and then have some trivial rule for handling port
positioning when you do something weird in script, like "ports always
deposit their normal nodes as the last children of a shadow node when
constructing the final flattened tree".  The important bit is that
output ports point to an element which will act as a container for the
normal-DOM nodes, not a position in the tree where the normal-DOM
nodes will be inserted.

Multiple ports sharing the same selector is easy - XBL2 already
handles it.  Ports are ordered, and you resolve the selectors in
order, letting the first match win.


>> If you mutate the shadow DOM without paying attention to the
>> outputPorts map, there are three possibilities for each port:
>>
>> 1. It points to a shadow node that wasn't mutated.  No change.
>>
>> 2. It points to a shadow node that was moved.  Everything currently
>> attached to that shadow node, and any new elements added to the
>> component which match the selector, will show up wherever the shadow
>> node was moved to.
>
> What if it was adopted into the main DOM, or moved to a different template
> instance?  Or are we going to forbid that?  This is the sort of thing XBL1
> in Mozilla tends to go crazy over.

Hierarchy error.  Shadow nodes need to be bound to their specific
shadow tree.  Anything else is psychotic, as you say.  ^_^

We *could* allow this, with an appropriate modification of
importNode() or some similar function that "sanitized" the node and
returned it to its pristine condition, removing output ports, etc.
But the notion that it still retains its magic powers when moved
elsewhere is clearly bad.


>> 3. It points to a shadow node that was removed.  Existing normal nodes
>> which were pointing to that shadow node now don't show up at all in
>> the final flattened tree
>
> I don't think that's acceptable, actually.  They should instead show up
> wherever they would have shown up if the node that was removed were not
> there to start with (e.g. a different port for the same selector).

That's a possibility, sure.  It implies that output ports are
re-resolved on every mutation of the component's contents.  I'm not
sure if this should be automatic, or just an option, or what.  It
should at least be possible to trigger such a re-resolution.


> You're missing:
>
> 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.


>> All of the cases I outlined above can be run into when you're mutating
>> a live template as well.  Are there additional cases I'm missing that
>> you have problems with?  Are they perhaps a result of having both a
>> mutable shadow and a live template?
>
> 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?

~TJ

Received on Wednesday, 15 December 2010 00:51:30 UTC