RE: ISSUE-88 - Change proposal (new update)

Re: ISSUE-88 - Change proposal (new update)
Hi, Lachlan, all:

 


From: Lachlan Hunt <lachlan.hunt@lachy.id.au> 
Date: Fri, 07 May 2010 11:34:48 +0200
> . . .
> Neither of these summaries describe any use case for why authors would want to specify multiple languages in the meta > element. The only reason given simply states that it should be allowed because HTML 4.01 and XHTML 1.0 permitted it. > That in itself is not a valid reason.
I think the purpose of specifying multiple languages is for when the content is directed to speakers of multiple languages; this information is not currently much used however so you are right in that.

 

Also -- the purpose of the meta http-equiv content-language tag is for when the server settings are not in the content author's control but those settings specify a language that the author wants to override.

The other option is overriding those with the html tag's lang attribute.  However the server settings and the html language attribute are, as you have said, not quite the same.

> . . .
> We also have some observational evidence [6] that indicates that a vast majority of authors only use a single value, 
> and that the minority of authors who do use multiple values, don't do so with the expectation of any significant or
> useful processing (except maybe a few who depend on it for the :lang() pseudo-class).
You are right in this too.
> . . .
> The element language fallback behaviour when taken from an HTTP Content-Language header containing multiple 
> langauges is to default to unknown. This is not useful behaviour for authors to explicitly choose by using multiple 
> languages in the meta element. They get the same result by omitting the Content-Language pragma from 
> the document.
Actually this depends on the browser.

 

> Your claim here does not make sense.  The HTTP Content-Language header 
> does allow multiple language tags, whereas the current HTML5 spec only 
> allows one.  So that claim quoted from the spec is indeed correct, as it 
> currently stands.
However everything depends on browsers -- is not that what Leif means?  Thus multiple languages in the http header
may or may not be processed and may or may not override an html lang tag set to lang= null which was Leif's real concern with all this.
> . . .
> Looking at the cases where the fallback behaviour will or will kick in, 
> we find the following:
> Case 1:
> <html lang="en">
> <head>
>  <title>Example>
>   <meta http-equiv="Content-Language" content="en">
> </head>
> The meta element here is completely useless.  The default language for 
> every will be obtained from the lang attribute, either on the html 
> element or a nearer ancestor.  Warning about it being useless seems 
> completely reasonable.
Authors should be told that it is useless simply because many browsers in many situations will ignore it as they ignored the html lang tag in the past?
(We should have, according to this logic, warned about the html lang tag's being useless in the past then.)
> Case 2:
> <html>
> <head>
>  <title>Example>
>   <meta http-equiv="Content-Language" content="en">
> </head>
I think this is where Leif wants a warning about the language information in meta http-equiv="Content-Language" 's being used as the fallback language --
and where I'd like the content creator to be told that  his/her text will be identified by browsers as English (in this particular case).
> . . .
>> 2. To hold the syntax rules of HTTP (which permits multiple language
>> tags) as the conforming ones (rather than those of @lang, which forbids
>> multiple languages), will have the effect of underlining that @lang and
>> Content-Language have different purposes.
> Again, use of the the Content-Language in the document has no other purpose.
I have no access to the server settings whatsoever; this is the case for many content authors; 
thus there is no way that my server settings can agree with my document language -- unless the language is strictly English which is the language my server always declares on my behalf; so my server settings need to be overridden 
-- what mechanism do you propose then for overriding these?  Simply the html lang tag?
Then the way that the html language tag information is used must be identical to the way the server settings are used.
Authors do of course have access to the html lang tag in most cases (and one can put a language attribute on a div element too),
but I personally would like the meta http-equivalent to be available when I want to override the server settings
with something other than the html lang attribute (for whatever reason) --
and in this case I would like the meta http-equivalent declaration to function much like the http server setting --
though normally I agree that's not its purpose.
Also to make the meta http-equivalent obsolete when it is FrontPage's way of letting the page creator select the language is somewhat questionable -- although perhaps Microsoft is satisfied with its being obsolete; I don't know.    
 
> And based on the way 
> you phrased the proposed requirement, the algorithm will have "kicked 
> in" before it gets to #5, but it's doesn't seem like you actually want a 
> warning in that case.
I personally would like a warning in this case as well. Thanks for noticing this!
Thanks and thanks for your thorough discussion, though I did not agree for the most part.

From: Julian Reschke <julian.reschke@gmx.de> 
Date: Fri, 07 May 2010 14:19:49 +0200
To: Lachlan Hunt <lachlan.hunt@lachy.id.au> 
> On 07.05.2010 13:57, Lachlan Hunt wrote:
>> ...
>> This is the case with http-equiv values of Content-Type,
>> Content-Language, Default-Style and Refresh. None of these values, when
>> they occur in the meta element, are ever, nor should they ever be, used
>> by server side processing.
>> ...
> 1) We have heard from at least one server implementer who does.
> 2) Why shouldn't implementers do what HTML4 says? What's the problem you 
> want to solve by making a change compared to what HTML4 says?
> Best regards, Julian
Thanks, Julian!  I am in agreement with you!
Also with John -- below!
 
Best,
C. E. Whitehead
cewcathar@hotmail.com 

> Date: Fri, 7 May 2010 09:08:45 -0400
> To: lachlan.hunt@lachy.id.au
> From: cowan@ccil.org
> 
> Lachlan Hunt scripsit:
> 
> > This is the case with http-equiv values of Content-Type, 
> > Content-Language, Default-Style and Refresh. None of these values, when 
> > they occur in the meta element, are ever, nor should they ever be, used 
> > by server side processing.
> 
> "Are ever" may or may not be true. "Should ever be" goes beyond the
> remit of a protocol. Servers are entirely free to use anything at all
> in the document for whatever processing purpose they desire, since it is
> servers who generate the version of documents provided to clients.
> 
> -- 
> I could dance with you till the cows John Cowan
> come home. On second thought, I'd http://www.ccil.org/~cowan
> rather dance with the cows when you cowan@ccil.org
> come home. --Rufus T. Firefly
>

Received on Friday, 7 May 2010 21:25:33 UTC