Re: Mutation events replacement

On 6/30/11 5:43 PM, Ryosuke Niwa wrote:
> On Thu, Jun 30, 2011 at 5:16 PM, Boris Zbarsky <bzbarsky@mit.edu 
> <mailto:bzbarsky@mit.edu>> wrote:
>
>     On 6/30/11 7:01 PM, Ryosuke Niwa wrote:
>
>         What do you mean by it being partially inserted?  Like document
>         relationship, etc... aren't consistent?
>
>
>     That would be one example, yes.  Firing mutation events as you go
>     involves making those relationships consistent at every step of a
>     multipart mutation, whereas in some situations it may be simpler
>     and faster to have intermediate inconsistent states.
>
>
> Yeah, I hear you.  It's particularly painful in the editing world 
> where we have to make multiple DOM mutations.
>
> I'd really like to know if having a list of mutations will address 
> David's use case.
>
> - Ryosuke
>
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

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.

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 suspect that there are a number of useful refinements that could be 
made to the mutationList details.  For example, a "ChildListReplaced" 
type would be nice when all the children of an element are blown away by 
setting innerHTML or textContent.   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.

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.  I'd suggest, therefore that mutationList not be an array 
but something more like an iterator or cursor with a next() method so 
that implementations don't have to pretend that this lazily filtered 
list is actually an array-like object.

     David