Re: Mutation events replacement

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