- 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