Bug 19431 - Namespace of elements made via .createElement() in XML documents must be null
Namespace of elements made via .createElement() in XML documents must be null
Status: REOPENED
Product: WebAppsWG
Classification: Unclassified
Component: DOM
unspecified
All All
: P2 minor
: ---
Assigned To: Anne
public-webapps-bugzilla
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2012-10-10 13:13 UTC by Aryeh Gregor
Modified: 2012-12-14 18:08 UTC (History)
8 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Aryeh Gregor 2012-10-10 13:13:03 UTC
createElement() says "Return a new element with no attributes, namespace set to the HTML namespace, local name set to localName, and node document set to the context object."  But this test outputs "true" in all browsers:

data:text/html,<!DOCTYPE html>
<script>
document.documentElement.textContent = 
document.implementation
        .createDocument(null, "", null)
        .createElement("x")
        .namespaceURI === null;
</script>

The namespace needs to be null if the context object is not an HTML document.
Comment 1 Ms2ger 2012-10-10 13:54:28 UTC
How about XHTML documents?
Comment 2 Aryeh Gregor 2012-10-10 14:08:27 UTC
Conclusion of IRC discussion:

  <AryehGregor> So you're saying that implementers will all have to change anyway, and what's specced is simpler than what all of them do now and believed to be compatible enough?
  <annevk> right
  <zcorpan> yeah

Gecko bug filed: https://bugzilla.mozilla.org/show_bug.cgi?id=799937
Comment 3 Olli Pettay 2012-10-10 14:22:50 UTC
(In reply to comment #2)
> Conclusion of IRC discussion:
> 
>   <AryehGregor> So you're saying that implementers will all have to change
> anyway, and what's specced is simpler than what all of them do now and
> believed to be compatible enough?
>   <annevk> right
>   <zcorpan> yeah
> 

The reasoning is?
Comment 5 Anne 2012-10-10 15:17:39 UTC
The idea is that all Document objects will implement all Document-related interfaces so that if you import script libraries it does not matter if you do in an HTML/XML/XHTML/SVG/etc. document.
Comment 6 Aryeh Gregor 2012-10-11 19:25:25 UTC
Testing in IE 10 Developer Preview, Firefox 19.0a1, Chrome 23ish dev, Opera Next 12.50 internal.  Tests in IE actually use a simple PHP script that sets the header, since it doesn't support data URLs for this.  I tested IE in both IE10 browser/document mode, and IE9 browser/document mode (not actual IE9).


This is "string http://www.w3.org/1999/xhtml" in all browsers:

data:text/html,<!DOCTYPE html>
<script>
var s = document.createElement("x").namespaceURI;
document.documentElement.textContent = 
typeof s + " " + s;
</script>


This is the HTML namespace in all five as well:

data:application/xhtml+xml,<!DOCTYPE html>
<html xmlns="http://www.w3.org/1999/xhtml">
<head><script>
var s = document.createElement("x").namespaceURI;
document.documentElement.textContent =
typeof s + " " + s;
</script></head><body></body></html>

But if you change the MIME type to "application/xml", it becomes null in IE9/Gecko/WebKit while staying the same in IE10/Opera.


This is still the HTML namespace in all five, removing the xmlns after the fact:

data:application/xhtml+xml,<!DOCTYPE html>
<html xmlns="http://www.w3.org/1999/xhtml">
<head><script>
document.documentElement.removeAttribute("xmlns");
var s = document.createElement("x").namespaceURI;
document.documentElement.textContent =
typeof s + " " + s;
</script></head><body></body></html>


This is the HTML namespace in IE10, but null in IE9/Gecko/WebKit/Opera:

data:application/xml,<!DOCTYPE html>
<html>
<head><script xmlns="http://www.w3.org/1999/xhtml">
var s = document.createElement("x").namespaceURI;
document.documentElement.textContent =
typeof s + " " + s;
</script></head><body></body></html>

But if I change the MIME type to application/xhtml+xml, it changes to the HTML namespace in IE9/Gecko/WebKit as well, while remaining null in Opera.


So it looks to me like in IE10 standards mode, the HTML namespace is always returned in every case I tested.  In IE9/Gecko/WebKit, the default namespace is determined by the MIME type that the page is served with.  In Opera it's dependent on the namespace of the initial root element, regardless of MIME type.  IE10 and Opera are not as likely to be web-compatible as the other three.  I move we standardize IE9/Gecko/WebKit -- it's the dominant behavior, and not really so much more complicated than what we have now, and what we have now matches no one but IE10 (probably because they changed to follow the spec).


Sill to be determined before we can write a spec: what happens if the document is created with document.implementation.createDocument?
Comment 7 Aryeh Gregor 2012-10-11 19:26:27 UTC
(Also should be noted for posterity: there was some pushback in https://bugzilla.mozilla.org/show_bug.cgi?id=799937 asking for why Gecko should bother changing its behavior and risking compat when we could just change the spec instead.  Implementers come before specification authors in priority of constituencies, so . . .)
Comment 8 Anne 2012-10-11 19:42:28 UTC
You are forgetting about developers though. Having different behavior for MIME types while effectively we treat all XML MIME types equal in most places is super weird. image/svg+xml and application/mathml+xml also seem relevant to test. As well as scripts running in image/jpeg derived HTML documents and such (see page loading in HTML).

Overall though, very much opposed to making this simple method very complex.
Comment 9 Simon Pieters 2012-10-12 08:42:32 UTC
(In reply to comment #6)
> This is still the HTML namespace in all five, removing the xmlns after the
> fact:
> 
> data:application/xhtml+xml,<!DOCTYPE html>
> <html xmlns="http://www.w3.org/1999/xhtml">
> <head><script>
> document.documentElement.removeAttribute("xmlns");
> var s = document.createElement("x").namespaceURI;
> document.documentElement.textContent =
> typeof s + " " + s;
> </script></head><body></body></html>

Removing the xmlns attribute doesn't change the namespace of the root element.

http://software.hixie.ch/utilities/js/live-dom-viewer/saved/1838

> In Opera it's
> dependent on the namespace of the initial root element, regardless of MIME
> type. 

s/initial/current/
Comment 10 Aryeh Gregor 2012-10-14 08:32:46 UTC
(In reply to comment #8)
> You are forgetting about developers though. Having different behavior for
> MIME types while effectively we treat all XML MIME types equal in most
> places is super weird.

Which developers, the three who serve stuff with an XML MIME type?

> image/svg+xml and application/mathml+xml also seem
> relevant to test.

Okay, will do.

> As well as scripts running in image/jpeg derived HTML
> documents and such (see page loading in HTML).

How does that work?  This doesn't seem to allow author scripts to run in image/jpeg-derived HTML documents:

http://www.whatwg.org/specs/web-apps/current-work/multipage/history.html#read-media

Or did you mean something else?

> Overall though, very much opposed to making this simple method very complex.

Me too, but making it a bit more complex doesn't seem like it should be a big deal -- not if it's just adding a switch on .contentType.

(In reply to comment #9)
> Removing the xmlns attribute doesn't change the namespace of the root
> element.
> 
> http://software.hixie.ch/utilities/js/live-dom-viewer/saved/1838
> 
> > In Opera it's
> > dependent on the namespace of the initial root element, regardless of MIME
> > type. 
> 
> s/initial/current/

Ah, thanks for the pointer.  Noted.
Comment 11 Anne 2012-10-14 09:11:38 UTC
Load an image or plugin in an iframe, get hold of the document object, and do your thing? Seems like that should work. But I suppose since they are handled by the HTML parser they will have the HTML document thingie set.
Comment 12 Aryeh Gregor 2012-10-15 10:12:27 UTC
I wrote a comment, but either I didn't submit it or it vanished.  I wrote tests, which test for the HTML namespace if .contentType is "text/html" or "application/xhtml+xml" and null otherwise:

http://w3c-test.org/webapps/DOMCore/tests/submissions/AryehGregor/Document-createElement-namespace.html

IE10 Developer Preview: 45/46 in both IE10 and IE9 mode; also returns HTML namespace if you do .createDocument(htmlNamespace, "html", null).createElement("x"), although the .contentType is still "application/xml"
Firefox 19.0a1: 46/46
Chrome 23 dev: 42/46; also returns the HTML namespace for application/xml if the original root element had the HTML namespace
Opera 12.50 internal: 24/46; uses a totally different algorithm, as discussed

I think this is not substantially more complicated and much more closely matches what browsers do.  Are there any objections to changing the spec to match this approach, or do we want browsers to change here?
Comment 13 Anne 2012-12-14 18:08:19 UTC
I would still prefer browsers to change as having something depend on MIME seems really counter-intuitive and has been a source of confusion in the past.

If everyone speaks up in favor of comment 12 though, I will play ball.