Re: Fwd: XBL2: First Thoughts and Use Cases

On 12/15/10 11:40 AM, Tab Atkins Jr. wrote:
> 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?

Because the new parent of the output port can have a binding attached 
itself, which puts them in different output ports under that shadow tree.

> True, but having them be anything other than elements complicates the
> handling of shadow DOM mutations.

I'm still looking for use cases for shadow DOM mutations that involve 
adding or removing nodes.  Why are these useful?  If they're not 
sufficiently useful, then given the specification and implementation 
complexity of supporting them I would propose that they be disallowed.

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

The range spec defines this, fwiw... ;)  But yes, there is less author 
control in this case; you can't choose whether the node goes before or 
after the port.

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

A component attached to every table cell in a large data table, say.  Or 
every email in your inbox.  Or every text input or checkbox or dropdown 
<select> (see Slashdot comment page while moderating).

These are all situations where I've seen people trying to use XBL1, fwiw.

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

Agreed.

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

For each output port the relevant CSS selectors.

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

A DOM tree in Gecko takes order of 40 bytes per node.  Just storing a 
single nontrivial CSS selector is comparable in size to a bunch of DOM 
nodes, last I checked.

-Boris

Received on Wednesday, 15 December 2010 20:32:31 UTC