createDocument() should use namespace to set content type

[annevk]

See #213 (comment) onwards for feedback from @ayg, @foolip, and @ArkadiuszMichalski on this.

[ayg]

What should we cover? XHTML, SVG, MathML, anything else?

[zcorpan]

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

Gecko/Presto	Chromium/WebKit	Edge
log: application/xml log: application/xml log: application/xml	log: application/xhtml+xml log: image/svg+xml log: application/xml	?

Also new Document()?

[foolip]

I tested in Edge and it's all undefined, because the contentType attribute isn't supported.

[annevk]

Note that Gecko has some varying based on the doctype, but I don't think anyone else does so that can hopefully be removed: https://bugzilla.mozilla.org/show_bug.cgi?id=520969.

[ayg]

I don't think Gecko actually varies contentType here, only the type of document produced (HTMLDocument vs. SVGDocument vs. XMLDocument).

[ArkadiuszMichalski]

@zcorpan new Document() is fresh and use default content type application/xml, any other engine than Gecko supports this constructor?

[zcorpan]

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

It seems WebKit also supports it; uses application/xml. However, that type is less useful than application/xhtml+xml given that createElement uses null as namespace. My thought is then if new Document() could be changed to application/xhtml+xml.

But maybe that conflicts with HTMLDocument vs. Document -- if we have to change how that works in the specs as well... http://software.hixie.ch/utilities/js/live-dom-viewer/saved/4058 logs false in WebKit/Chromium/Gecko.

[ayg]

I think we should make the same change for new Document(), because it's more useful to have a reasonable .contentType.

[foolip]

Somewhat on topic, it would be neat if contentType could replace https://dom.spec.whatwg.org/#concept-document-type and thereby the "HTML document", so that all document type tests could be of the type done in #213

[zcorpan]

@ayg I agree it would be more useful, but it would be particularly weird if we then have to split Document and HTMLDocument. If that happens maybe a better thing to do is to provide a constructor for HTMLDocument?

[annevk]

@foolip that seems rather tricky, since we need to enumerate all possible content type values that HTML uses for HTML documents then.

[foolip]

I was hoping it was just text/html, or that at least it'd be web compatible to always return text/html if it's treated as an HTML document, but maybe I'm being too optimistic?

[annevk]

The HTML standard requires numerous content types for text loading, media loading, etc.

[ayg]

@zcorpan Why would we have to split Document and HTMLDocument?

[annevk]

However, perhaps the supported set of XML content types would be small enough. Anyway, we should really discuss this in a distinct issue.

[zcorpan]

@ayg hopefully we don't, but nobody has implemented what's currently specified.

[ayg]

@zcorpan Okay, but how would this relate to splitting Document and HTMLDocument? (Which maybe we should split anyway, #221.)

[zcorpan]

If new Document() creates a Document of type application/xhtml+xml, that would be inconsistent with loading an application/xhtml+xml resource into a browsing context which would instead be HTMLDocument (I assumed, but reading #221 maybe HTMLDocument can be used only for "html" mode documents instead, if it is unmerged...)

[ayg]

Hopefully we won't have to split them, and if we do the difference should be marginal (one or two methods or properties different), so it doesn't bother me much.