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

Re: Proposal to make Content-Language pragma non-conforming altogether for ISSUE-88 (mark I)

From: Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no>
Date: Fri, 9 Apr 2010 03:15:37 +0200
To: Ian Hickson <ian@hixie.ch>
Cc: public-html@w3.org
Message-ID: <20100409031537495312.bd3f197b@xn--mlform-iua.no>
Ian Hickson, Fri, 9 Apr 2010 00:00:51 +0000 (UTC):
> ISSUE-88

> SUMMARY
> People are confused by the Content-Language pragma, so it should be made 
> non-conforming.

I could have accepted this change, if it said that 

a) Still, a last,  empty (and thus cancelling) content-language 
talisman is still permitted:
   <meta http-equiv="content-language" content="" />
b) As long as a last, empty content-language talisman is used, then the 
conformance requirements of possible preceding META content-language, 
are laxed.
   <head>
     <meta http-equiv="content-language" content="en,fr" />
     <meta http-equiv="content-language" content="," />
     <meta http-equiv="content-language" content="" />
   </head>

 [...]
> IMPACT
> 
> POSITIVE EFFECTS
> * Removes any remaining confusion about the appropriateness of the use of 
>   the Content-Language pragma.

No, it does not. Because: 

a) You did not make any changes to the language determination 
algorithm, in which content-language will still take part. This will no 
doubt confuse authors. 
b) Thus, vendors are still required to implement features that they do 
no implement today - such as listening to the HTTP header for a 
language, whenever the document itself doesn't have a META 
content-language or any <html lang="*">
c) There is still the Mozilla confusion:
   http://malform.no/testing/html5/attr-lang/mozilla-lang-lottery/

   Allthough KHTML, Webkit, Chrome can also be affected - by 
non-conforming documents:
   http://malform.no/testing/html5/attr-lang/mozilla-lang-lottery/kwc


> * Saves authors time since it's one less thing to worry about.

For the more advanced authors, it hides complexity - see especially 
point c) above.

> NEGATIVE EFFECTS
> * Will flag harmless uses of the pragma in legacy documents when they are 
> updated. Data suggests this affects ~8% of pages [1], though ~5% of 
> another sample were using the pragma incorrectly anyway [2].

There doesn’t exist such a thing as "harmless uses". META 
content-language in the way they are implemented in KHTML, Webkit, 
Chrome and Mozilla browsers always "breaks the model" of lang="" and 
xml:lang="". The same is true also for HTTP content-language - it 
breaks the model in Mozilla.

The cure for this is to specify how one can *avoid* the harm from META 
content-language and HTTP content-language - see above and here:

http://malform.no/testing/html5/attr-lang/mozilla-lang-lottery/fixed


> CONFORMANCE CLASS CHANGES
> Authors and conformance checkers are affected.
> 
> RISKS
> This might cause wasted time for a small percentage of authors who are 
> currently using the pragma in a harmless fashion and want to update their 
> pages in a way that validates to HTML5.

In addition, it causes a real problem for those authors that want to 
benefit from HTML5’s alignment of empty xml:lang="" and empty lang="". 
In legacy web browsers, then the semantics of xml:lang="" and lang="" 
are impossible to get - cross browser, unless one either uses the "fix" 
I pointed to above - or simply disable HTTP content-type on the server 
side as well. 

Meaning that as long as legacy browsers play any role, then authors 
must for example choose between using content-language negotiation or 
the semantics of empty lang=""/xml:lang="".
-- 
leif halvard silli
Received on Friday, 9 April 2010 01:16:13 GMT

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