Re: Mutation events replacement

On 20/07/11 00:56, Jonas Sicking wrote:
> On Tue, Jul 19, 2011 at 4:18 PM, Ryosuke Niwa<rniwa@webkit.org>  wrote:
>> For editing purposes, it's also crucial to know from/to where nodes are
>> removed/inserted.  It seems like adding an offset trivially solves this
>> problem without much overhead.
> I'm not really sure how you're expecting to use indexes. Not that once
> one node is removed, the index changes for all other nodes. Can you
> provide a short example code demonstrating how you'd use the index?

Actually, this is what I use in my editing app. The serialization of a 
change involves a tumbler naming scheme for DOM nodes based upon the 
child number, e.g.    "4.2.1" identifies 1st child of the 2nd child of 
the 4th child of the editing root element. With the current mutation 
events, the application script has to compute these reference strings 
and can do so because of the synchronous nature of existing mutation 
events, and the knowledge that this particular application doesn't 
mutate the DOM within such mutation event handlers.

For the notification scheme, this could be computed by the browser, and 
it would be critical for the notification array of changes to be in the 
sequence in which they occurred. This allows other editing clients to 
apply the changes correctly, despite the reference string changing as 
nodes before or above it are inserted or removed.

If the notification scheme only supplies the index number for the node 
that was inserted/removed/changed the app will need a way to find the 
index numbers for that node's ancestors at the time the mutation took 
place.  This presents challenges since the notified sequence of 
mutations may have altered the index number for the node's parent 
(perhaps even removing it from the tree) subsequent to the mutation in 
question.  A two pass algorithm may be possible that uses the state of 
the DOM tree *after* the sequence of mutations has been applied to 
compute the tumbler for each node at the time a given mutation occurred 
given the child number reported for the mutation. This index number 
needs to be the position at which a new child was added, or the position 
of the child that was removed.

I would much prefer the notification to supply the tumbler for the node 
based upon a designated root element, supplied when the notification 
observer was registered.  If you are concerned with the cost of 
computing the tumbler, this could be done only when the application 
requests it.

p.s. there should be a lightweight means to temporarily disable 
notifications when the application performs house keeping operations on 
the DOM tree.

-- 
  Dave Raggett<dsr@w3.org>  http://www.w3.org/People/Raggett

Received on Wednesday, 20 July 2011 08:56:01 UTC