On 7/1/11 12:13 PM, Boris Zbarsky wrote:
On 7/1/11 3:05 PM, David Flanagan wrote:
I don't think I really explained my use case on this list. See
https://bugzilla.mozilla.org/show_bug.cgi?id=641821#c23 and
https://bugzilla.mozilla.org/show_bug.cgi?id=641821#c25
And https://bugzilla.mozilla.org/show_bug.cgi?id=641821#c26 please....
Yes, that too. I agree that my use case is different than the one that
Olli's proposal is addressing. But Ryosuke asked about my use case :-)
> Similarly, I've found it important to
be able to distinguish between nodes that are being removed from a
document tree and nodes that are being moved within the document tree,
Interesting, given that Gecko's DOM implementation does NOT make such
a distinction at the moment. Why did you find this to be important?
As I see it, the test of sufficiency of set of mutation event is if you
can use them to mirror a document tree. And in my case I'm trying to do
that across a process boundary where I can't share nodes--I have to
serialize everything to a string or something similar. If I call
appendChild() on a node that is already in the tree, that removes it
from its current parent and inserts it into a new parent. If that
generates a remove event and then an insert event I'll end up having to
completely re-serialize the node (and all of its children) to re-insert
it from scratch into the mirror tree. If the appendChild() generates a
move event then I can simply serialize the fact that an existing node
has moved. There are probably ways I could make this work without a
move event, but that's why I found it useful to make the distinction.
Implementations will presumably maintain one list of all current
mutations, and then will have to filter that list to deliver only those
that match the desired type and desired subtree for which a listener is
registered.
That's unclear. Maintaining this list (if it were done) sounds very
expensive; in Gecko's case we're more likely to drop on the floor the
ones which have no registered listeners.
Sure, but if there were multiple listeners on different subtrees,
listening for different types of events, would you
built up a custom mutation list for each one as the mutations were
occuring? Or build up one master list and then filter it lazily when
the events are dispatched?
David
-Boris
