[TxMt] Misguided use of content-type in XHTML/1.1 template

[porneL]

On Mon, 05 Mar 2007 01:11:22 -0000, Allan Odgaard  
<throw-away-1 at 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).

-- 
regards, porneL