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

On Apr 3, 2010, at 5:34 PM, Ian Hickson wrote:

> On Sat, 3 Apr 2010, Leif Halvard Silli wrote:
>> Ian Hickson, Fri, 2 Apr 2010 18:54:23 +0000 (UTC):
>>   []
>>  []
>>> The same change proposal also suggests a second change, namely to  
>>> change
>>> the syntax to allow multiple comma-separated language codes, even  
>>> though
>>> all but the first would be ignored.
>>> User agents do not pay any attention to values after the first.
>> Incorrect: Except Mozilla browsers (which looks at *all* the language
>> tags in the list), user agents do not pay attention to <meta>
>> content-language at all when it contains a comma-separated list.
> You are correct, I misspoke.
>>  []
>>> Even if there was such a need, this feature would be a bad way to  
>>> provide
>>> that information, since it is used in an incompatible way by user  
>>> agents
>>> (the first language, and only the first language, is used to  
>>> determine
>>> processing behaviour -- none of the languages are treated as a  
>>> target
>>> audience language hint).
>> Some incorrectness. Se note above.
> Indeed. I should have said that it was a bad way to provide the
> information since it causes user agents other than Mozilla to ignore  
> the
> information altogether.

I'd still like to see a test case, so people can check this for  
themselves. Given Leif's information, here's my take (personal opinion  

I think the processing requirements should be updated to match Mozilla  
(so implementations are permissive in what they accept). But the  
authoring requirements should allow only a single value, to maintain  
compatibility with legacy UAs (since a comma would cause non-Mozilla  
pre-HTML5 browsers to ignore the language information entirely).

>> That makes up four incorrect claims. I don't think that the WG  
>> should be
>> asked to vote for something which can be easily documented as  
>> incorrect
>> claims.
> Agreed. I retract the mark II proposal; I shall put forward a third
> proposal that is more accurate.

Looking forward to the new version.


Received on Sunday, 4 April 2010 00:52:12 UTC