RE: Null change proposal for ISSUE-88 (mark II): proposed note

 

Hi!

 

From: Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no> 
Date: Mon, 12 Apr 2010 14:14:31 +0200

> CE Whitehead, Sun, 11 Apr 2010 19:29:55 -0400:
>> Hi, Leif, all!

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

>> ME] Well, if we have both the html lang declaration and the meta 
>> content-language declaration as options,
>> authors always can choose to use one, or the other, or ignore both
>> and hope that defaults will work.

> They are options. But they are not meant as options for the same thing. 
> Hence it is quite odd that that an best praxis guide present them on an 
> equal footing. To, in addition - as I feel that Richard now does - use 
> this erroneous juxtaposition as an argument for making META 
> content-language illegal, makes even less sense.
 
>> However, I thought that both a language specification in the html tag
>> and in addition a language specification in the http header or a meta 
>> Content-language element
>> were both essential to good practice.

> Yes. But they live in different rooms - conceptually.
ME] Absolutely -- and thus normally it's the html lang= attribute that can be set to null, the empty string;
however the meta content-language which expresse audience or content negotiation language
would not be set to null;
but here you are asking that the meta content-language attribute 
be used to override language preferences set incorrectly by the server
or to override an html lang= attribute misinterpreted at the processing end.

So it's my understanding that you want the content-language attribute to be usable 
as a substitute for the html lang= attribute.

And that is fine with me.

( NOTES:  I used to work as a VISTA -- 
and had to set up a web site for a non-profit 
in the space hosted by the (now pretty much defunct) Arlington Community Network.
Our host took our content and essentially pasted it into their page body, 
their page borders being lined with various advertisements which paid for the space;
the only way to put in our style codes or language declarations was to use
the css style codes somewhere inside a div in the page body;
the same could be done for meta content-language -- but I honestly do not know how that was interpreted by the processors
[definitely though this makes a case for having the last meta content-language attribute used to substitute for the text-processing language
where the html lang= attribute cannot be interpreted properly or is absent]. 
I could have had JavaScript functions declared within the div too! --
sloppy coding yes but what do you want?
My html head section was stripped away as was my body tag
leaving only a div tag to set everything I wanted to set to override defaults.

So your recommendations are absolutely fine with me!

I do like html's robustness in this regard: 
I do think we have to continue to give authors the flexibility in this one language;
css and JavaScript on the other hand are not so robust; case matters  for css names and for JavaScript;
with xml and xhtml every element has to have a closing tag as well as an opening declaration;
but at least html is so so free!)

Best,
C. E. Whitehead
cewcathar@hotmail.com
 
>>> 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="".
>> 
>> ME] Yes
>> 
>>> 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?
>> ME] Agreed.  This would be a problem.
>> (Content-authors mess things up and processors mess things up but I 
>> think it's the w3c's job to
>> specify recommendations for documents as properly as possible.)

> Indeed.
> -- 
> leif halvard silli