On 20/07/11 00:56, Jonas Sicking wrote:
On Tue, Jul 19, 2011 at 4:18 PM, Ryosuke Niwa<rn...@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<d...@w3.org> http://www.w3.org/People/Raggett
