This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
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.
How about XHTML documents?
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
(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?
http://krijnhoetmer.nl/irc-logs/whatwg/20121010#l-1042
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.
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?
(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 . . .)
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.
(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/
(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.
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.
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?
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.
(In reply to Anne from comment #13) > 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. At this stage implementations haven't changed, is there any indication that they will? I sympathise with your point that having a single behaviour in all contexts is nice for libraries, but I'm not sure it's the path forward. My (admittedly somewhat dated) experience with trying to use off-the-shelf libraries in e.g. image/svg+xml contexts when they were created and tested for HTML is that they tend to fail for all sorts of reasons already. This tells me it's just not something do, and I don't think we should be encouraging it. We should be transitioning people to sending SVG and friends as text/html (with matching syntax) and just have XMLDocument and its ilk specified as they exist today and slowly pushed down the road to obsolescence.
I think I may be able to get IE/Edge to change to match Gecko/WebKit in this regard. I think interop is more important then following the letter of the spec, so we should just get the spec to change to match reality.
It seems to me that the spec for this could be quite simple. It already includes an HTML-specific check, so just tweak it slightly: 1. If localName does not match the Name production, throw an InvalidCharacterError exception. 2. If the context object is an HTML document: 2.1. Let localName be converted to ASCII lowercase. 2.2. Let interface be the element interface for localName and the HTML namespace. 2.3. Return a new element that implements interface, with no attributes, namespace set to the HTML namespace, local name set to localName, and node document set to the context object. 3. Otherwise, return a new element with no attributes, namespace set to the null, local name set to localName, and node document set to the context object. This is what Blink does, does it match everyone else? Anne, would changing the spec like this be OK with you?
Philip, that's incorrect per comment 6. And running that testcase in Chrome confirms that application/xhtml+xml documents (which are not HTML documents) also create elements in the HTML namespace.
OK, Blink actually says "if (isXHTMLDocument() || isHTMLDocument())", and I was assuming that both of these were under the "HTML document" umbrella in the specs. Not so, it seems. Per spec, are "HTML document" and "XML document" the only two categories and mutually exclusive? At least Blink has isHTMLDocument(), isXHTMLDocument(), isXMLDocument() and isSVGDocument(), so perhaps that's a complication. What would you actually like the spec to say? Precisely what it already says?
Yes, HTML (text/html) and XML (everything else) are mutually exclusive. I prefer the current specification, but I could live with embracing multiple document types if nobody sees a way out. Not exactly the end of the world.
We tried having createElement create things in the HTML namespace in random XML documents in Gecko, and within hours had reports of breakage in widely used extensions. Given that this specification breaks such things and matches exactly 0 actual UAs if I read this bug correctly, we will be reverting the change. I recommend changing the spec to more closely match actual UA behavior.
You should also take into account behaviour for document created by DOMParser.parseFromString(), especially of the type "application/xhtml+xml", because I see this: - Firefox and Opera (Presto) always return new elements with null as namespace. - Chrome/IE11 always return new elements with HTML namespace. It seems that the behaviour of createAttribute method is highly dependent on how we create the document. I wonder how it looks like for XMLHttpRequest.responseXML, or other "context of creating a document".
https://github.com/whatwg/dom/pull/213
Not sure the spec change is web compatible https://github.com/whatwg/dom/pull/213#issuecomment-223953388