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 16:56 ------- I agree that the order of event delivery is clearly unspecified, so in most cases the removal and insertion could come in any order. (Too bad they didn't have an atomic "replacement" event in the spec, oh well.) But according to Section 1.1.1 in DOM Level 2 Core, a Document may have at most one Element child. I think it's reasonable to conclude from this that it is an error for a DOM implementation to ever allow clients to observe it in a state where a Document has two Element children. For this reason, I think it's necessary that replacing the document element necessarily involves sending the removal first -- so that the intermediate state is still a valid one for a Document. On getDocumentElement(): I guess if the removal event came first, the proper result of getDocumentElement during event delivery would be null, since the document is in a state with no root element. During insertion event delivery, getDocumentElement() should return the new element, consistent with the fact that insertion events are delivered after the child is visible inside the parent. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
