- 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
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 UTC