- From: Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no>
- 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). 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. > 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="".) 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] 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. [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 -- leif halvard silli
Received on Sunday, 21 March 2010 11:48:33 UTC