W3C home > Mailing lists > Public > public-html@w3.org > April 2010

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

From: Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no>
Date: Tue, 6 Apr 2010 16:45:20 +0200
To: Jonas Sicking <jonas@sicking.cc>
Cc: Ian Hickson <ian@hixie.ch>, Julian Reschke <julian.reschke@gmx.de>, Anne van Kesteren <annevk@opera.com>, Kornel Lesinski <kornel@geekhood.net>, public-html@w3.org
Message-ID: <20100406164520863496.1fc0fcf1@xn--mlform-iua.no>
Leif Halvard Silli, Tue, 6 Apr 2010 01:16:28 +0200:
> Jonas Sicking, Sun, 4 Apr 2010 21:03:04 -0700:
>> On Sun, Apr 4, 2010 at 7:55 PM, Leif Halvard Silli
>> <xn--mlform-iua@xn--mlform-iua.no> wrote:
>>> Leif Halvard Silli, Sun, 4 Apr 2010 04:37:55 +0200:
>>>> Ian Hickson, Sat, 3 Apr 2010 22:38:12 +0000 (UTC):
>>>>> On Sat, 3 Apr 2010, Julian Reschke wrote:
>>>>>> On 04.04.2010 00:34, Anne van Kesteren wrote:
>>>>>>> On Sat, 03 Apr 2010 02:00:32 -0700, Julian Reschke wrote:
>>>>>>>> The attribute is an HTML attribute, but it's value space is 
>>>>>>>> defined by
>>>>>>>> the HTTP header registry.
>>>   [...]
>>>>> http-equiv isn't anything to do with HTTP in practice. HTML5 just makes
>>>>> that clear. Ideally we'd drop the whole attribute, but 
>>>>> unfortunately there
>>>>> are some pragmas that are needed for backwards-compatibility. I 
>>>>> agree that
>>>>> some people will object (indeed, you have already objected). What 
>>>>> matters
>>>>> isn't whether anyone agrees, what matters is that we make the right
>>>>> technical decisions that are compatible with reality.
>>>> 
>>>> I am arguing that to continue to allow white-space as well as continue
>>>> to allow a comma separated list is more compatible with reality, than
>>>> forbidding one or both. Bug 9264. Your reaction to Bug 9264 was that I
>>>> should file bugs against user agents! (To "save" the spec.) Why should
>>>> I file bugs against vendors if your spec matches user agent reality?
>>> 
>>> I have reopened bug 9264, under a new title,
>>> 
>>> "There should be a link/border between [the] META content-language
>>>  algorithm and HTTP content-language headers"
>>> 
>>> because Mozilla browsers (which were the background for bug 9264)
>>> actually behave according to the HTML5 draft.
>>> 
>>> http://www.w3.org/Bugs/Public/show_bug.cgi?id=9264#c7

>> 
>> For what it's worth, I think we at mozilla would be quite happy to
>> change our behavior, as always. However, as always, it's under the
>> condition that it
>> 
>> 1. Improves behavior over what we are currently doing.
>> 2. Doesn't break too many pages.
>> 
>> Obviously both these points are quite subjective. I can't give an
>> answer to "how many is too many?", nor is it always easy to say what
>> is an "improvement".
> 
> To day I have filed a bunch of bugs related to META content-language. 
  [...]
> Bug 9422: Mozilla and <META http-equiv="content-language" 
> content="<emptystring>" >. Mozilla needs to make a small change so that 
> it treats the empty string correctly. 

Jonas: I filed a first bug with Mozilla, related to this issue: [1]

"Bug 557507 - Treat the empty string inside META content-language 
identical with lang="<emptystring>" (like, basically, all non-gecko UAs 
do)"

I think this bug should be quite uncontroversial and break extremely 
few pages - if anyone. I hope this can become the first step towards 
alignment content-language in all UAs.

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=557507

-- 
leif halvard silli
Received on Tuesday, 6 April 2010 14:45:59 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 9 May 2012 00:17:07 GMT