DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24310>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24310

Document.replaceChild calls listeners during invalid state





------- Additional Comments From [EMAIL PROTECTED]  2003-11-04 19:03 -------
Sorry, I was being silly -- getDocumentElement() should return the old root
during the removal event dispatch (assuming remove was first), since removals
are sent before the change actually takes place.

I've now searched some more and found more information on the history of this
problem, including your (Joe's) thread on the subject from Oct. 1999 #. Though I
agree it's far from clear, I'd argue that not being able to observe the document
in a non-sensical state is consistent with "You may have some events in which
there is only one way to do things, and thus we don't need to specify order." *

The reason this becomes an important issue (at least for me) is when using
mutation events to record all changes for the purpose of being able to later
undo them. If replacing the root element can come as an insertion first, this
means that the listener has to very delicately special case this situation,
since it can not legally undo the two atomic events in the order received. (If
it did so, it would first undo the removal, which would result in trying to
insert a second root element momentarily.) However, if the order is reversed,
performing the individual atomic changes works as expected -- undoing the
replacement is simply removing the old root and then inserting a new one.

Perhaps I should persue this with the DOM spec as well?

# http://lists.w3.org/Archives/Public/www-dom/1999OctDec/0032.html
* http://www.w3.org/DOM/L2CR2comments_public.html#Events

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to