On Apr 16, 2008, at 9:36 AM, William F Hammond wrote:
About 7 years ago there was argument in these circles about whether correct xhtml+mathml could be served as text/html. As we all know, a clear boundary was drawn, presumably because it was onerous for browsers to "sniff" incoming content and then decide how to parse. As things have evolved, we now know that browsers do, in fact, perform a lot of triage. See, for example, "Mozilla's DOCTYPE sniffing", http://developer.mozilla.org/en/docs/Mozilla's_DOCTYPE_sniffing Especially since we are speaking about dual serialization of the same DOM and since there is relatively little use of "application/xhtml+xml" (and some significant user agents do not support it), might it not be worthwhile to re-examine the question of serving standards-compliant xhtml or xhtml+(mathml|svg) serialized document instances as either "text/html" or "application/xhtml+xml"? In other words, why not be able to serve both serializations as "text/html"? What obstacles to this exist?
It's not entirely clear what your proposal is, but I assume you are suggesting that content served as text/html with an XHTML doctype declaration should be parsed as XML. The obstacle to this is that much text/html content has an XHTML doctype declaration but depends on being parsed and otherwise processed as HTML, not XML, as current user agents do it. Such content is fairly widespread due to the legacy of Appendix C. It is preferable to let the MIME type continue to be the switch rather than making the doctype serve this role.
An additional obstacle in the case of HTML5 is that the XML serialization does not have a distinct doctype (they may use the common HTML5 doctype or no doctype at all, which when parsed as text/ html would be treated as an HTML document in quirks mode).
Regards, Maciej
