Re: Fwd: XBL2: First Thoughts and Use Cases

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

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

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

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

-Boris

Received on Wednesday, 15 December 2010 19:14:43 UTC