- From: Jonas Sicking <jonas@sicking.cc>
- Date: Sun, 4 Apr 2010 21:03:04 -0700
- To: Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no>
- 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
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". However I don't want anyone to think that our behavior is set in stone. / Jonas
Received on Monday, 5 April 2010 04:03:56 UTC