1

I was encountering issues on a page with a XHTML doctype sent with MIME of application/xml.

Firefox 3.6 was the only browser where the body element background was no longer occupying the full page when in application/xml mode as it should (http://stackoverflow.com/questions/5225237/background-of-body-element).

Is this supposed to happen? Should having an MIME of plain XML with a DOCTYPE of XHTML be treated as an XHTML webpage?

Hawken
  • 2,059
  • 19
  • 34
  • Not sure what you mean by "treated as a valid XHTML webpage". Browsers don't care about validity. Pages served as `application/xml` will be parsed with an XML parser, and therefore must be XML well-formed, but it seems you've achieved that. If Firefox 3.6 is doing one thing, and later Firefoxes doing something else, you've probably just hit a FF 3.6 bug. Post some markup+CSS, we may be able to suggest a workaround. – Alohci Jun 28 '12 at 07:46
  • I mean should XML with a DocType be parsed the same as XHTML+XML with a DocType? – Hawken Jun 28 '12 at 13:33
  • Having run some tests, this is an interesting question +1. Unfortunately I don't know the answer. Firefox definitely treats `application/xml` differently to `application/xhtml+xml`. Even in the latest version, `document.body` is undefined in `application/xml` I don't know what, if any, specification would cover this. – Alohci Jun 28 '12 at 21:44

1 Answers1

0

Using the same quote in https://stackoverflow.com/a/5225321/271577 , it is dependent on the root element. Although an exception may be made for XHTML, if the content-type is not recognized through detection (whether DOCTYPE sniffing, namespace checking, etc.), then it is likely that the XML is not likely to be rendered as XTHML, but rather as XML.

XML can be rendered with CSS, even though it does not have default styling assigned to any elements as in XHTML (since it is meant to be a language to define one's own language). To assign styling, as in XHTML, one must in particular choose whether the element is to use display: block; or display:inline.

The XML specification does not make mention of DOCTYPE sniffing, and this practice has been discouraged by some for XML: http://hsivonen.iki.fi/doctype/#xml in favor of namespaces and processing instructions.

But per https://developer.mozilla.org/en/Mozilla%27s_DOCTYPE_sniffing , Firefox before 4.0 "sniffing only occurs for documents sent as text/html" and application/xml should "trigger full standards mode". However, this is in reference to distinguishing different HTML modes; to identify XHTML out of XML, at https://developer.mozilla.org/en/XML_in_Mozilla , I believe the following may be suggesting that a recognized PUBLIC DOCTYPE was supposedly used to distinguish XHTML from "pure" XML:

Please note that the XHTML entities, like ä, work only in conforming XHTML documents that have a valid XHTML Formal Public Identifier (or in other words, a DOCTYPE section with a PUBLIC identifier). XHTML entities will not work in arbitrary XML documents, not even if the XHTML namespace is used." which is then followed by a list of valid identifiers.

But if you were using a recognized PUBLIC DOCTYPE and it was still not treated as true XHTML (e.g., with ability to style the body tag alone, without needing to style the html root as well--a practice I seem to recall may have been necessary, at least earlier, for XHTML/HTML polyglot documents), then my guess would also be that it was a bug. I would also think that a namespace should have been sufficient (and without a namespace, it shouldn't work since XML+Namespaces requires one for application-specific behavior).

Community
  • 1
  • 1
Brett Zamir
  • 14,034
  • 6
  • 54
  • 77