Re: [tlug] Firefox 3.0.1 doesn't respect <meta http-equiv="content-type">

[Curt Sampson <cjs@example.com>]

On 2008-09-14 23:49 +0900 (Sun), Stephen J. Turnbull wrote:

> Puh-lease.  I'm talking about calling the content of the HEAD element
> a "header".  That's just encapsulation, just like having a TCP header
> inside (as part of the content of) an IP packet.  That TCP packet
> itself might contain another TCP packet or even IP.  No?

The one very important difference you ignore here is that in the TCP/IP
protocol suite, aside from perhaps a few things related to bootstrapping
protocols, there are no cases of encapsulated data changing the meaning
of data outside the encapsulation, or providing information for layers
of encapsulation outside of itself. It doesn't make sense, since
encapsulation is no longer a transparent, reversable operation, and
causes problems like the ones we're seeing here.

> In fact, I don't see how the inner protocol can modify
> the interpretation of the outer protocol, since it doesn't know what
> that protocol is.

Well, that's an issue, but without question META http-equiv tags mess
about with the interpretation of the HTTP headers, if present.

> By the time the inner protocol gets interpreted,
> the outer protocol's meta information is gone.

Nope. The browser, when interpreting the HTML, remembers and uses the
information (such as the charset) from the headers.

>  > Is actually *not* an attempt to reset the content type, but is
>  > specifying (in a terribly unobvious way) the default character
>  > encoding for the document.
> 
> I don't understand what you mean. It's not an attempt to reset the
> content type, nor does it have anything to do with "default" character
> sets.

Well, sorry, you may say it doesn't, but the spec says it does:

    The META element may be used to specify the default information for
    a document in the following instances:

	* The default scripting language.
	* The default style sheet language.
	* The document character encoding.

>  > Presumably this:
>  > 
>  >  <META http-equiv="Content-Type" content="image/jpeg; charset=ISO-8859-5"> 
>  > 
>  > is also a valid way of doing it;
> 
> No, because image/* content types don't have a charset parameter.

Right, but there's no indication in the spec that it should not be
interpreted that way. In fact, the spec seems to go out of its way not
to say that the above won't work; it requires

    A META declaration with "http-equiv" set to "Content-Type" and a
    value set for "charset".

cjs
-- 
Curt Sampson       <cjs@example.com>        +81 90 7737 2974   
Mobile sites and software consulting: http://www.starling-software.com