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
