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: Sun, 4 Apr 2010 04:37:55 +0200
To: Ian Hickson <ian@hixie.ch>
Cc: Julian Reschke <julian.reschke@gmx.de>, Anne van Kesteren <annevk@opera.com>, Kornel Lesinski <kornel@geekhood.net>, public-html@w3.org
Message-ID: <20100404043755600190.9b5417e1@xn--mlform-iua.no>
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
>>> <julian.reschke@gmx.de> wrote:
>>>> The attribute is an HTML attribute, but it's value space is defined by
>>>> the HTTP header registry.
>>>> 
>>>> Changing this in general *will* cause objections (yes, those).
>>> 
>>> Please stop the drama. In the ten years it was deployed it was never
>>> implemented as HTML4 specified. No wonder its semantics are being
>>> changed to match reality.
>> 
>> I was just stating a fact.
>> 
>> The fact that browsers do not implement this doesn't mean it isn't used 
>> in documents.
> 
> 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

However, their implementation is - unanimously - not as one would 
expect it to be: They should given priority to what the server 
content-language says. But instead they give priority to what the 
<meta> content-language says.

> 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?
-- 
leif halvard silli
Received on Sunday, 4 April 2010 02:38:28 UTC

This archive was generated by hypermail 2.3.1 : Monday, 29 September 2014 09:39:16 UTC