The behavior of createElement and createElementNS is confusing. 1. createElement() creates elements with the xml namespace "http://www.w3.org/1999/xhtml" even though neither IE or Fx has that behavior. 2. createElementNS() behaves differently if the first argument is null or undefined. I think there is an incorrect string conversion occurring in the underlying code. Consider the following examples: $ var d = window.document.implementation.createDocument("", "", null); $ d.appendChild(d.createElement("foo")); $ (new XMLSerializer()).serializeToString(d); = <foo xmlns="http://www.w3.org/1999/xhtml"></foo> $ (new XMLSerializer()).serializeToString(e.evaluate("//foo", d.documentElement, null, null, null).iterateNext()); = $ var d = window.document.implementation.createDocument("", "", null); $ d.appendChild(d.createElementNS(null, "foo")); $ (new XMLSerializer()).serializeToString(d); = <foo/> $ (new XMLSerializer()).serializeToString(e.evaluate("//foo", d.documentElement, null, null, null).iterateNext()); = <foo/> $ var d = window.document.implementation.createDocument("", "", null); $ d.appendChild(d.createElementNS(window.undef, "foo")); $ (new XMLSerializer()).serializeToString(d); = <foo xmlns="undefined"/> $ (new XMLSerializer()).serializeToString(e.evaluate("//foo", d.documentElement, null, null, null).iterateNext()); =
(In reply to comment #0) > 1. createElement() creates elements with the xml namespace > "http://www.w3.org/1999/xhtml" even though neither IE or Fx has that behavior. This is by design, although there's a considerable disagreement on this point, even among WebKit developers. The idea is that scripts written for HTML should continue to work with XHTML, if at all possible. > 2. createElementNS() behaves differently if the first argument is null or > undefined. I think there is an incorrect string conversion occurring in the > underlying code. Both WebKit and Firefox 2 produce '<foo xmlns="undefined"/>' - could you please clarify what the bug is?
Ok, then I guess this bug just comes down to my #1. On #2, I hadn't noticed that Firefox's behavior matches Safari's because in Firefox we just use createElement instead of createElementNS. I happened to notice the odd difference in behavior between null and undefined only because of the particulars of our code that wraps the native XML classes. Since on #2 Safari's behavior matches Firefox, I have no complaints other than #1.
This was an intentional change, but looking at bug 8007 comment 16, I'm not sure if the issue can be considered closed.
(In reply to comment #0) > The behavior of createElement and createElementNS is confusing. > > 1. createElement() creates elements with the xml namespace > "http://www.w3.org/1999/xhtml" even though neither IE or Fx has that behavior. This is the standard behavior according to HTML5, for HTML documents. If you call createElement() on an XML document, you'll get the null namespace. This change is because in HTML5, HTML elements in HTML documents are now in the XHTML namespace instead of in the null namespace, for consistency. > 2. createElementNS() behaves differently if the first argument is null or > undefined. I think there is an incorrect string conversion occurring in the > underlying code. Technically, only strings or the null value are allowed for the namespace argument, and null is treated the same as the empty string. Anything else is converted to string, and thus the undefined value turns into the string "undefined". So this is also correct. > > Consider the following examples: > > $ var d = window.document.implementation.createDocument("", "", null); > $ d.appendChild(d.createElement("foo")); > $ (new XMLSerializer()).serializeToString(d); > = <foo xmlns="http://www.w3.org/1999/xhtml"></foo> > $ (new XMLSerializer()).serializeToString(e.evaluate("//foo", > d.documentElement, null, null, null).iterateNext()); > = > > $ var d = window.document.implementation.createDocument("", "", null); > $ d.appendChild(d.createElementNS(null, "foo")); > $ (new XMLSerializer()).serializeToString(d); > = <foo/> > $ (new XMLSerializer()).serializeToString(e.evaluate("//foo", > d.documentElement, null, null, null).iterateNext()); > = <foo/> > > $ var d = window.document.implementation.createDocument("", "", null); > $ d.appendChild(d.createElementNS(window.undef, "foo")); > $ (new XMLSerializer()).serializeToString(d); > = <foo xmlns="undefined"/> > $ (new XMLSerializer()).serializeToString(e.evaluate("//foo", > d.documentElement, null, null, null).iterateNext()); > = All of this is correct behavior per spec, assuming you do it in an HTML document.
Mass moving XML DOM bugs to the "DOM" Component.