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 14:22 ------- This may or may not be desirable, but as far as I can tell it's not an error per se. The DOM spec carefully avoided specifying the order in which events are thrown in order to leave maximum room for optimization. I don't think there was a promise that intermediate stages of compound operations such as replaceChild were promised to be completely well-formed DOMs. I do agree that special-casing Document, rather than using the general Node.replaceChild(), might be appropriate. On the other hand, since there's no guarantee what order any other DOM presents these in, I'd say code which is counting on this specific sequence should probably be considered nonportable and avoided when possible. > 1) Remove old root element, firing node_removed event. During this event > delivery, I think getDocumentElement should return the about-to-be-added new > root, even though it is not get a child of the document. Uhm. I can't find justification for doing that last in the DOM spec. This is once again getting into areas which are going to be nonportable... --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
