Re: Mutation events replacement

On Fri, Jul 1, 2011 at 12:05 PM, David Flanagan <dflanagan@mozilla.com>
 wrote:
>
> The sketch that Rafael has provided does look like it would address my
> needs.  Not because all the mutations are batched into a single list (though
> that seems like the most important feature of his proposal) but because his
> example has finer granularity than what Jonas and Olli have proposed:
> Rafael's sample mutationList array provides arrays of inserted and removed
> nodes rather than just providing notification that the child list has
> changed.
>

Glad to know someone likes his proposal as well :)  I think this is
important in many apps that need to sync data with their internal model or
states, or implement their own undo stack.

Rafael's proposal seem harder to specify and implement, since it defines a
> data structure rather than just a sequence of events, but it does seem
> compelling.  I have not yet grokked what it is that triggers a batch of
> mutatiions to be sent out, but if that aspect of the proposal is not
> problematic, I love the array of fine-grained     mutation details part.
>

I don't think it's particularly hard to implement but one obvious drawback
will be that we'd have to maintain a list that may or may not consume a lot
of memory space.  But this is necessarily anyway because we'd have an event
queue for asynchronous events.

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, and it would be good if the mutationList were
> defined in such a way that these two cases could be distinguished.
>

I think this will be really hard to implement.  For example, consider the
following code:
var parent = node.parentNode;
parent.removeChild(node);
setTimeout(function () {parent.appendChild(node), 0);
This script removes a node, then adds it back to the document later
asynchronously.  In this case, the mutation observer will be called before
the node was re-inserted to parent, and the user agent will report that the
node has been removed instead of being moved.

Also, consider the following case, in which the order in which move happened
is ambiguous:
var parent = node.parentNode;
parent.removeChild(node);
var grandparent = parent.parentNode;
grandparent.removeChild(parent);
node.appendChild(parent);
grandparent.appendChild(node);
On one hand, parent is appended to node first so maybe we should report that
parent moved to node first.  But on the other hand, the node hadn't been
attached to the document when the parent was appended.

I'm certain there are many other examples where the notion of "moved" won't
work well.

On Fri, Jul 1, 2011 at 12:13 PM, Boris Zbarsky <bzbarsky@mit.edu> wrote:

> On 7/1/11 3:05 PM, David Flanagan wrote:
>
>> 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.
>

I agree.  We don't need to match the presentation to JavaScript with UA's
implementations.  We should instead strive to make sure the interface to
JavaScript is easy to use correctly and consistent with other APIs.

- Ryosuke