W3C home > Mailing lists > Public > public-webapps@w3.org > October to December 2010

Re: XBL2: First Thoughts and Use Cases

From: Boris Zbarsky <bzbarsky@MIT.EDU>
Date: Tue, 14 Dec 2010 16:25:46 -0800
Message-ID: <4D080B0A.9090808@mit.edu>
To: "Tab Atkins Jr." <jackalmage@gmail.com>
CC: Dimitri Glazkov <dglazkov@google.com>, public-webapps <public-webapps@w3.org>
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).

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

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

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.

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

Received on Wednesday, 15 December 2010 00:26:25 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:13:14 UTC