- From: Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no>
- Date: Sat, 10 Apr 2010 18:13:00 +0200
- To: Richard Ishida <ishida@w3.org>
- Cc: 'Ian Hickson' <ian@hixie.ch>, public-html@w3.org
Richard Ishida, Fri, 9 Apr 2010 10:04:48 +0100: >> We can make the pragma entirely non-conforming instead of conforming >> with a warning, if that would help. > > I have indeed been coming to the same conclusion over the past week, and I > discussed it with i18n folks on Wednesday and got no major objections > (though the i18n Chair, Addison, wasn't in the discussion, so I don't know > his view yet - and he's on vacation for another 10 days). The chair's words were clear enough: [1] ]] The Internationalization working group maintains that, for compatibility with existing documents, authoring practice, and non-browser tools and user-agents, the existing syntax of HTML <meta> Content-Language really MUST be preserved. We do thank you for the other changes, but herewith request that the remainder of our Change Proposal be accepted by the HTML WG. [[ Even though his evaluation of the state of affairs does no quite concur with the evaluation found in the Best praxis Note that you produced in 2007: [2] ]] Best Practice 6: Choosing between Content-Language and attributes Use language attributes rather than HTTP or meta elements to declare the default language for text processing. Discussion: The basic reason is that current user agents rarely use information in the HTTP header or meta element for text-processing language applications, and such implementations as there are are inconsistent (see the test results). [[ I have to say though, that the dilemma, "Choosing between Content-Language and attributes", is an oddly formulated one - I did not know that I could choose ... And also, when @lang is the correct feature to use, then it is strange, to hear that the reason for using @lang is that it *works* better than content-language - one misses the more principal justification. For example the word "fallback" doesn't occur at all in that note. In that note, I can also not find any discussion of of the main problem with Content-Language, as I see it: That it interferes with the interpretation of an empty lang=""/xml:lang="". [...] > I'm inclined to think that deprecating its use by authors by > making it non-conforming, would be the best solution. It would > certainly significantly simplify the explanations of how authors > should declare language information in HTML as we go forward. Here I don't follow. The I18N wg can develop advice about how to (not) use content-language, independent of HTML5. There is nothing in the current state of affairs which requires you to formulate the dilemma "Choosing between Content-Language and attributes". In a Best practise document about @lang and content-language, how will you explain to authors how they can avoid the problem that Content-Language (the HTTP headers) interferes with Gecko's interpretation of lang="" and xml:lang="", if it is not permitted to place Content-Language meta element inside the document which can be used to cancel this effect? If forbidding Meta Content-Language makes the I18N WG think that it suddenly became much simpler to give advice, then I think that this is a reason to to not remove Content-Language, because the fact of the matter is that Content-Language constitutes a problem/challenge regardless. It is better to keep Content-Language and instead to define how to avoid the problems that it poses. [1] http://lists.w3.org/Archives/Public/public-html/2010Apr/0065 [2] http://www.w3.org/TR/i18n-html-tech-lang/#ri20040808.110827800 -- leif halvard silli
Received on Saturday, 10 April 2010 16:13:37 UTC