Re: Null change proposal for ISSUE-88 (mark II)

Anne van Kesteren, Sun, 04 Apr 2010 11:55:21 +0200:
> On Sun, 04 Apr 2010 04:37:55 +0200, Leif Halvard Silli 
> <xn--mlform-iua@målform.no> wrote:
>> Ian Hickson, Sat, 3 Apr 2010 22:38:12 +0000 (UTC):
>>> Browsers _do_ implement it, contrary to HTML4, which intends it for
>>> servers, who don't implement it. You may wish to recheck your facts.
>> 
>> Incorrect: Browsers implement it *because* HTML4 say that can do it. It
>> is not against HTML4 to do so. See
>> http://www.w3.org/TR/html4/struct/dirlang#h-8.1.2

> 
> Actually, that does not talk about <meta http-equiv>, just about HTTP.

The point which you need to understand is that to HTML4, the wording 
"http header" relates to both the content of <meta> http-equiv elements 
as well as to the "proper" http headers which originate from the 
server. Both are http headers. See my earlier comment to the section in 
question: [1]

}}
It is also untrue for another reason: HTML4 does make clear that it 
sees content-language as one and the same thing, regardless of whether 
it comes from server or from the <meta> c-l tag. The third step in the 
section "Inheritance of language codes" of HTML4 says: [2] 

]] The HTTP "Content-Language" header (which may be configured in a 
server). For example:
   Content-Language: en-cockney  [[

As you can see, it doesn't even use a <meta> c-l element in the example 
- instead it shows a HTTP header - despite that the preceding text 
*does have in mind* the <meta> c-l element: "The HTTP 
"Content-Language" header (which may be configured in a server)".
{{

When the text says that it "may be configured on the server", then it 
also follows that may also be configured another place than in the 
server. Namely in the document itself, in the <meta> http-equiv 
content-language element.

[1] http://lists.w3.org/Archives/Public/public-html/2010Apr/0102

-- 
leif halvard silli

Received on Sunday, 4 April 2010 17:07:56 UTC