We're observing pretty varying behaviour for .contentType, looking at this test:

    http://w3c-test.org/dom/nodes/Document-createElement-namespace.html

Parts of the failures are for synthetic documents. For those, both WebKit and Blink use the content type that would "ideally" match the namespace given to createDocument() instead of "application/xml". I somehow suspect that the issue (at least in the way in which it is implemented) is related to bug 19431.

Other failures, notably in Blink, apply to remotely-loaded documents, notably involving attempts to change the content type by swapping the root element while loading:

    Vanilla load XHTML as application/xml: http://w3c-test.org/dom/nodes/Document-createElement-namespace-tests/xhtml.xml
    Try changing to SVG: http://w3c-test.org/dom/nodes/Document-createElement-namespace-tests/xhtml_ns_changed.xml
    Try changing to without namespace: http://w3c-test.org/dom/nodes/Document-createElement-namespace-tests/xhtml_ns_removed.xml


The externally-loaded ones likely ought to be handled by other specifications that build DOMs (in this case HTML), but I am including them in case the additional data helps.

The synthetic cases however ought to be defined by the DOM, and we're lacking interoperability today. Gecko sticks to the spec (Unless stated otherwise, a document's (...) content type is "application/xml") but it would seem that no one else does. It is worth tracking whether this is something that implementers wish to align on or not.