setAttributeNode behavior when node was created with createAttributeNS

• Component: DOM
• Status: RESOLVED INVALID

[Robert Sayre]

WebKit and Opera 9 appear to preserve namespaceURIs on attribute nodes that are inserted with setAttributeNode instead of setAttributeNodeNS.

See Mozilla bug for test cases:
https://bugzilla.mozilla.org/show_bug.cgi?id=371552

[Alexey Proskuryakov]

I believe WebKit is correct when preserving the namespace in setAttributeNode().

As you mention in your b.m.o report, the spec doesn't say what setAttributeNode() does for namespaced attributes. However, there is a non-normative note that seems to make the intention clear, see section 1.1.8 of DOM 2 Core (or section 1.3.3 of DOM 3 Core):

----------------------------------------------
Similarly, using Element.setAttributeNode(newAttr), one can set two attributes (or more) that have different Node.nodeNames but the same Node.prefix and Node.namespaceURI. In this case Element.getAttributeNodeNS(namespaceURI, localName) will return either attribute, in an implementation dependent manner. The only guarantee in such cases is that all methods that access a named item by its nodeName will access the same item, and all methods which access a node by its URI and local name will access the same node.
----------------------------------------------

[Alexey Proskuryakov]

So it appears that Firefox is the only modern browser that disagrees with the (non-normative) spec text here. As real life compatibility risk seems to be pretty low, I'm closing this bug as INVALID.

[Lucas Forschler]

Mass moving XML DOM bugs to the "DOM" Component.