Re: Fwd: XBL2: First Thoughts and Use Cases

On Wed, Dec 15, 2010 at 11:14 AM, Boris Zbarsky <bzbarsky@mit.edu> wrote:
> On 12/15/10 10:51 AM, Tab Atkins Jr. wrote:
>> Yes, output ports can be moved.  I don't have any particular use-case
>> for it, but under the current conceptual model for how output ports
>> work, it's simpler to allow it than to disallow it, because output
>> ports are just elements.
>
> It significantly complicates implementation; when an output port is moved
> you have to find all the elements in the flattened tree that came "through"
> the output port and move them to different places (note that they don't all
> end up in the same place, in general).

If all you're doing is moving the output port, why wouldn't all the
associated normal-DOM elements end up in the same place?  Mutating the
output port would obviously cause changes, and the final box-tree for
CSS can indeed be changed in non-trivial ways, but I'm not immediately
seeing any reason why the final flattened tree would be changed in any
extraordinary way.


>> I think that having output ports be elements is a good and simple
>> answer, because we want output ports to be insertion points, not
>> containers.
>
> Sure.  But them being insertion points can happen without being elements.
>  For example, an insertion point can be tracked conceptually as a collapsed
> range (e.g. similar to the way a caret works in text controls; that too is
> an insertion point).

True, but having them be anything other than elements complicates the
handling of shadow DOM mutations.  I don't think there's a
non-arbitrary answer to what happens if the shadow tree contains
*only* an output port (as a collapsed range) and then you append a
child to the shadow tree.  Does the range go before or after the node?
 Is there any way to make this obvious to an author?

I'm not wedded to the "output ports are elements in the shadow DOM"
idea, but I think it's a pretty strong idea.


>>> At least in Gecko's case, we still use XBL1 in this way, and those design
>>> goals would apply to XBL2 from our point of view.  It sounds like you
>>> have
>>> entirely different design goals, right?
>>
>> Sounds like it.
>
> OK, so given contradictory design goals, where do we go from here?

Hmm, good question.  To start, I don't think I fully understand the
value of the situation you outline as a design goal.  What sort of
situation do you envision where you want to optimize producing tens of
thousands of components on a single page?

In the long term, if our use-cases truly are contradictory or
incompatible, then we can decide if it's worthwhile to approach each
case independently with different solutions.  We need to look at
use-cases first, though, so we can decide exactly what problems we're
trying to solve.


>> Under this model, existing components already expose all their DOM
>> separately every time, as real live DOM nodes in the document, so
>> instantiating fresh shadow for each instance of a component is no
>> worse.
>
> Sure.  And Gecko instantiates a fresh shadow tree copy for each instance.
>  However you're suggesting also instantiating a fresh copy of various
> metadata, whose size can easily dwarf the size of the shadow tree itself.

I don't think I agree with that characterization.  The necessary
metadata isn't very large:

1. A list of output ports.

2. For each output port, a list of which normal-DOM descendants of the
component are associated with that port.

3. A list of attribute forwards (a map from name to node/name).

4. A list of pseudos (a map from idents to shadow nodes).

5. Other stuff?

This is a few NodeLists and a few maps, comparable in size to a small
DOM tree I'd think.  Am I missing something?

~TJ

Received on Wednesday, 15 December 2010 19:41:42 UTC