- From: David Flanagan <dflanagan@mozilla.com>
- Date: Fri, 01 Jul 2011 12:43:51 -0700
- To: Boris Zbarsky <bzbarsky@MIT.EDU>
- CC: public-webapps <public-webapps@w3.org>
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
Received on Friday, 1 July 2011 19:44:20 UTC