- From: Maciej Stachowiak <mjs@apple.com>
- Date: Thu, 04 Mar 2010 02:44:32 -0800
On Mar 4, 2010, at 2:27 AM, Stewart Brodie wrote: > Boris Zbarsky <bzbarsky at MIT.EDU> wrote: > >> On 3/3/10 12:11 PM, Stewart Brodie wrote: >>> As far as I can tell, this affects: HTMLSelectElement.add(), >>> HTMLOptionsCollection.add(), Node.appendChild(), Node.replaceChild >>> (), >>> Node.insertBefore(). >> >> Is it option-specific, though? Last I checked, various browsers >> implicitly adopted on append/insert/replace, period. > > Since when? I was sure that they didn't used to do this. DOM Core is > extremely clear on this issue (both in level 2 and level 3). You > appear to > be correct: Firefox and Opera both just ignore the standard and get > this > wrong. Chrome just seems to get confused. In WebKit, we originally implemented the rule required by the DOM spec, but found that was insufficiently compatible with the Web. Below see our current rule. I think this should be errata'd in the DOM to give a more reasonable behavior. // WRONG_DOCUMENT_ERR: Raised if newChild was created from a different document than the one that // created this node. // We assume that if newChild is a DocumentFragment, all children are created from the same document // as the fragment itself (otherwise they could not have been added as children) if (newChild->document() != document()) { // but if the child is not in a document yet then loosen the // restriction, so that e.g. creating an element with the Option() // constructor and then adding it to a different document works, // as it does in Mozilla and Mac IE. if (!newChild->inDocument()) { shouldAdoptChild = true; } else { ec = WRONG_DOCUMENT_ERR; return; } }
Received on Thursday, 4 March 2010 02:44:32 UTC