Bug 14835 - createElement(x) vs. createElementNS(null,x)
Summary: createElement(x) vs. createElementNS(null,x)
Status: RESOLVED INVALID
Alias: None
Product: WebKit
Classification: Unclassified
Component: DOM (show other bugs)
Version: 523.x (Safari 3)
Hardware: Mac OS X 10.4
: P2 Normal
Assignee: Nobody
URL:
Keywords:
Depends on:
Blocks: 10489
  Show dependency treegraph
 
Reported: 2007-07-31 13:04 PDT by Jesse Costello-Good
Modified: 2019-02-06 09:03 PST (History)
6 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Jesse Costello-Good 2007-07-31 13:04:21 PDT
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());
=
Comment 1 Alexey Proskuryakov 2007-07-31 13:23:17 PDT
(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?
Comment 2 Jesse Costello-Good 2007-07-31 14:50:38 PDT
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.
Comment 3 Alexey Proskuryakov 2007-08-01 06:40:01 PDT
This was an intentional change, but looking at bug 8007 comment 16, I'm not sure if the issue can be considered closed.
Comment 4 Maciej Stachowiak 2010-01-07 01:30:11 PST
(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.
Comment 5 Lucas Forschler 2019-02-06 09:03:57 PST
Mass moving XML DOM bugs to the "DOM" Component.