On Mon, 05 Mar 2007 01:11:22 -0000, Allan Odgaard throw-away-1@macromates.com wrote:
This is completly misguided as <meta> is there only for backwards- compatibility non-XHTML user-agents -- that is only those which *do not* support application/xhtml+xml.
From W3C XHTML FAQ: "Note that a meta http-equiv statement will not be recognized by XML processors, and authors SHOULD NOT include such a statement in an XHTML document served as 'application/xml' (and 'application/xhtml+xml' as well for that matter)."
The reason it says SHOULD NOT (which means “not recommended”, see RFC 2119) is that for an XML document, you declare the content type using processing instructions. Though I have no idea how the “content type” processing instruction looks, anyone?
If document is sent with application/* content-type, you can declare character set of XML document using XML declaration (which is often mistaken for processing instruction), but there's no way of declaring content-type (MIME type) that I'm aware of.
Please change it back to text/html or remove <meta> element completly.
The type of an XHTML 1.1 document is application/xhtml+xml, so if we want to actually serve XHTML, we should not change it
There are only two cases: 1. If XHTML is served as XML (using any of the recommended XML media types), the <meta> is completly ignored, so it doesn't matter whether there is application/xhtml+xml, text/html or video/mpeg - it's ignored, irrelevant and cannot affect document in any way. 2. if XHTML is served as text/html, the <meta> with application/xhtml+xml states contradictory information. <meta> cannot change processing mode and even if it could - it would lead to case #1.
we can’t IMO rely on the document always being served over http.
XHTML relies on externally specified media type already. Browsers even parse local XHTML files differently basing on content-type supplied by the OS (or file extension).