- From: CE Whitehead <cewcathar@hotmail.com>
- Date: Thu, 20 May 2010 19:20:58 -0400
- To: <xn--mlform-iua@xn--mlform-iua.no>, <mark@macchiato.com>
- CC: <fantasai.lists@inkedblade.net>, <public-html@w3.org>, <public-i18n-core@w3.org>, <www-international@w3.org>, <ian@hixie.ch>, <hsivonen@iki.fi>, <addison@lab126.com>, <jonas@sicking.cc>
- Message-ID: <SNT142-w2364BBAED88E9932B9557B3E30@phx.gbl>
Hi, Leif, all: Thanks Leif very much for considering a compromise. I guess I'd love compromise, but I do not particularly like making the meta http-equiv entirely in error because it is still being used by browser makers -- I'd prefer a warning not an error message -- and truthfully I never have seen the reason you all have that it is a problem here; (If it is a major problem I need data -- more than the following which I see as unproblematic and showing a preference for meta http-equiv http://www.w3.org/International/tests/tests-html-css/tests-language-declarations/results-language-declarations) However I find it preferable to have the meta http-equiv an outright error rather than having it non-conforming to the http header. The latter option is way too confusing I think though perhaps it would be better to hear from browser and application makers as far as the confusion issue goes -- since I worry most about confusion on their part. (I'm not sure why as I am sure most know the standards as well as . . . so it's just questionable in terms of how they will try to make things work and what they will do for compatibility with existing content and applications -- so they not I will have to decide here I think [not that I want to change my own content; I don't; but I set the html lang anyway; just so long as the browsers will parse my html content as it is I do not care about validator warnings or error messages) For my part I'd like to see more affirmation of the lang= null attribute in the wording on content-language. Otherwise I like Leif's previous proposal, but I will consider a compromise that does not start kicking out error-mesages, but I'd love to hear from someone else. Thanks! Best, --C. E. Whitehead cewcathar@hotmail.com From: Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no> Date: Thu, 20 May 2010 03:49:14 +0200 To: fantasai <fantasai.lists@inkedblade.net> Cc: Henri Sivonen <hsivonen@iki.fi>, Addison Phillips <addison@lab126.com>, public-i18n-core@w3.org, public-html@w3.org, Jonas Sicking <jonas@sicking.cc> Message-ID: <20100520034914125374.ece5a399@xn--mlform-iua.no> fantasai, Wed, 19 May 2010 02:21:44 -0700: > On 05/19/2010 02:06 AM, Henri Sivonen wrote: >> "Addison Phillips"<addison@lab126.com> wrote: >> >>> - HTML should (continue to) strongly recommend the presence of @lang >>> (and warn in validators if it is not present) >> >> If validators did that, there'd be even more templates, etc., filling in a >> placeholder value that doesn't necessarily have anything to do with the >> actual content. > > In that case, I would suggest following Leif's suggestion and only > posting a warning about a missing lang="" if the Content-Language > HTTP header or <meta http-equiv> pragma is present. This is more > likely to catch authors who are trying to specify the language but > doing so wrongly, and avoid the authors who don't care. Don't you think that making the pragma an outright error *could* work, provided that the language fallback warning from my current change proposal is implemented as well? I see 3 differences from Ian's "Make Content-Language pragma non-conforming" proposal: A. validators/spec would not ask authors to "use @lang instead"; B. validators would show an additional warning in case the pragma caused the fallback language measure to kick in; C. validators would warn if the C-L HTTP header caused language fallback; The warning for B. and C. should ask authors to take control via html@lang. Advantages: 1. Limits the actual fallback- fallback in the wild is more often caused by pragma than by HTTP. (MAMA showed pragma to be used 10 times as often as HTTP.) 2. Naturally increases focus on @lang 3. A step towards the ideal goal which the I18NWG expressed in their feedback: that we get rid of fallback. 4. doesn't assume that authors misunderstand C-L. Disadvantages: - It might be confusing that the C-L pragma may affect the document language despite being invalid - who will notice it? This is the why I suggest to show both a fallback warning (if it kicks in) as well as an error - to make authors aware. Such a warning can also limit the occurrence of bogus language tags. - Inability to validly implement "fallback" without a server. Comments: A., B. and C. differ from Ian's proposal to make the pragma invalid. Regarding A.: to tell authors to "use @lang instead of pragma" assumes that all authors have the same misinterpretation about the semantics of the Content-Language pragma. It is better to remain completely silent on what to do "instead", rather than assuming any particular (mis)understanding. Eventually one should also list HTTP C-L as an alternative to the C-L pragma. Regarding B.: I am open to discussing to not implement (B), in case two error messages instead of only one would seem confusing. Regarding C.: An alternative to (C) could be to require UAs to not use HTTP as basis for fallback. -- > leif halvard silli
Received on Thursday, 20 May 2010 23:21:37 UTC