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

Ian Hickson, Sun, 4 Apr 2010 00:34:29 +0000 (UTC):
> On Sat, 3 Apr 2010, Leif Halvard Silli wrote:
>> Ian Hickson, Fri, 2 Apr 2010 18:54:23 +0000 (UTC):
...
>> As for consistency with earlier specifications: That can be verified as 
>> untrue by looking at *the* earlier specification, HTML4. (Not to talk 
>> about the HTTP spec.)
> 
> I am not sure what you are referring to here. What claim is incorrect?

Julian's reading of HTML4 is that HTML4 is silent on this issue. [1]  
If so (not sure what exactly he meant), then you claim above about 
consistency with earlier specifications is wrong, for that reason. 

But perhaps Julian meant this: HTML4 allows both whitespace as well as 
a comma separated list inside the content attribute. Your change 
proposal does not allow this. Thus it breaks with HTML4, and thus your 
claim is untrue. (The HTML4 permission of whitespace is important, as 
I've argued in another bug 9264.)

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)".

And here we have another problem with your proposal: A HTTP header 
should be given priority over any <meta> element inside <head> (that is 
how <meta> charset is treated). But, as we know, user agents do not do 
that when it comes to <meta> c-l. Well, they do, when it comes to 
content-negotiation (one of the original purposes of c-l http header). 
But when it comes to using the c-l HTTP header for fallback, then user 
agents in practise give priority to the <meta> element, if present. 
Also, they give priority to the *last* <meta> c-l. 

OK. But then your text propose that they start to look *not at the 
last* but at the *first* <meta> c-l. What for? If you ask that user 
agents make such a drastic change with regard to what they give 
priority, why not ask them to give priority to the server instead? If 
you asked them to give priority to the server, then I would be OK with 
requiring UAs to look at the first <meta> c-l element (whenever there 
is more than one present). Asking user agents to go the half way is 
hardly helpful. Then it is better to remain at the point where one 
already is. (And user agents are united in this: They all give priority 
to the last <meta> c-l. And they also all give priority to the <met> 
c-l instead of giving priority to the server.) Why require change, for 
so little?

And, btw, I18N group: why don't you make the same point?

[1] http://www.w3.org/mid/4BB703B0.4020201@gmx.de
[2] http://www.w3.org/TR/html4/struct/dirlang.html#h-8.1.2
-- 
leif halvard silli

Received on Sunday, 4 April 2010 02:22:21 UTC