RE: ISSUE-88 / Re: what's the language of a document ?

Hi.

Thanks Leif for all your info on browsers (all I have is IE8; I occasionally have access to Mozilla but rarely; I need to download some but I have a tiny tiny machine).


All my backgrounds came out lime in IE8,
but I think there is an error in your style codes:

<style>body:lang(en) {background:red} body {background:lime}</style>

Are these ordered right?

<style>body {background:lime} body(lang:en){background:red}</style>

(ignore the lt gt stuff if you see it; that's for display)

or rather --
style type ="text/css"
body { background: lime; }
body:lang(en) { background: red; }
/style
(but I did not read your source code for this)

Or else the lime background for the body is going to over-write any sub-types of the body?

However for some reason my browser ignores all but the general styling anyway
(that is it ignores the language-specific styling; see attached!)
More comments below!

(If you reply to this, do not expect an immediate reply;
but best of luck with getting the browsers straightened out)
RE ISSUE-88 / Re: what's the language of a document ?
Date: Sun, 21 Mar 2010 12:47:56 +0100
To: CE Whitehead <cewcathar@hotmail.com> 
Cc: ian@hixie.ch, www-international@w3.org, public-html@w3.org, ishida@w3.org 

CE Whitehead, Sat, 20 Mar 2010 19:31:21 -0400:

> I do already use the meta content-language element to override the 
> http header my server sends -- as the meta content element is within
> my control, but the server  settings are not
> (my server certainly does send http headers out for my pages; I've 
> checked on it; but it does not send the ones I want it to send).

> Override? I doubt it. If you have really overridden it, then you should 
> now be able to re-check it and verify that it has indeed changed. 
> Simply dropping the <meta> content-language element does not 
> automatically override what your server sends – unless your server 
> reads the <meta> content-language before it sends out the header. (And 
> it seems like only Roy Fielding knows about CMS-es and Web servers that 
> behave like that.)

> The HTTP header always has precedence over the <meta> http-equiv 
> element in your document. So, it does for example not matter if you 
> specify in a <meta> element that the document is served as 
> 'application/xhtml+xml' if your server sends it out as 'text/html'. And 
> ditto for content-language: Specifying that your document is for French 
> and English users in the <meta> content-language element doesn't change 
> anything on the server side.

> On the other side: If you use the <meta> content-language header for 
> another purpose than the server side function, then I agree that you 
> have overridden it - to the extent that the consumer(s) you have in 
> mind (which could include yourself) gives priority to what is inside 
> the document instead of giving priority to what the server says.

> As for using <meta> content-language as a way to set the language of 
> the document, then this is 100% a secondary/derived function. But even 
> for this secondary function, user agents are supposed to (per the specs 
> that are recommended today) give priority to what the server says. The 
> fact of the matter is that they don't prioritize in that order, 
> however, they instead look at the <meta> element in the document first 
> (only IE and Firefox listen to the server at all). 
All I have is IE, and yes it listens to what the server sends, so no I have not been able to over-write that.
(But I use the meta content-language element to try to do so.)

> So what is the secondary effect that you are after? If it is the 
> language of the document you are seeking to specify, then you should 
> use <html lang="<MY-LANGUGE>"> instead.
Of course.  Unless I want lang to = "" and have two languages declared further down.
We agree on this it seems.
>> I would suspect that surrounding a document's content with <div 
>> lang=""> would solve the problem with Mozilla where html="" or xml="" 
>> is ignored -- that seems to me to be a solution that the browsers
>>can handle today. Am I right at least in this regard?

> (I don't know what you mean by html="" and xml="" - I'll assume you 
> meant lang="" and xml:lang="".)
Yes.
> No, you are not right. The Mozilla family of web browsers, per the 
> HTML5 spec (but not per HTML4 or XHTML1) *should* have behaved like 
> that. But they don't. Chrome/Webkit/Konqueror also don't. You can try 
> any of these browsers in test case 1. [1] And then see that all is fine 
> if you add a second white-space filled <meta> c-l, see test case 2. [2]
Interesting.
> In truth, Chrome/Webkit/Konqueror behave a little different from 
> Mozilla browsers. You can verify this in test case 3. [3] Test case 3 
> is identical with test case 1, except that it has <html lang="ru">. The 
> Mozilla browser family and the Chrome/Webkit/Konqueror family treat 
> test case 3 differently, but neither treat it correctly. But in the 
> end, and over all, the Mozilla browser family is more correct - it only 
> has this glitch with regard to how it reacts to <meta> content-language 
> (which is possible for authors to deal with by providing a white-space 
> filled <meta> c-l element), whereas the other browser family also has 
> an error with regard to how it treats the lang attribute. As you can 
> confirm in test case 4 (which is identical with test case 3, except 
> that it has a second, whitespace filled <meta> element). [4]

> PS: Internet Explorer 8 also has a whole host of bugs w.r.t. how it 
> inherits the lang="" attribute. E.g. for an element which is child of 
> an element with an empty lang=""  then IE8 fails to respect it. But 
> those bugs do no relate to <meta> content-language. 
Thanks for the info.  

> [1] http://software.hixie.ch/utilities/js/live-dom-viewer/saved/412
> [2] http://software.hixie.ch/utilities/js/live-dom-viewer/saved/415
> [3] http://software.hixie.ch/utilities/js/live-dom-viewer/saved/417
> [4] http://software.hixie.ch/utilities/js/live-dom-viewer/saved/416

However, all my backgrounds came out lime for my IE browser,
suggesting that IE in each case interpreted the language as "",
but I think there is an error

( ? and in any case my IE browser ignores language-specific styling it seems; I can't get it to do otherwise )

Best, 

C. E. Whitehead
cewcathar@hotmail.com
> -- 
> leif halvard silli

Attachments

Received on Monday, 22 March 2010 03:10:02 UTC