This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
In bug 9440 it is suggested that the empty string shall have the meaning "unknown language". This in order to align user agent's treatment of <meta> content-language and lang="*". Also see bug 9417. However: the empty string is currently not Mozilla compatible. Mozilla will instead EITHER visit the *preceding* (the earlier) HTTP-EQUIV element - if there is any. OR it will visit the HTTP server's content-language header. A workaround for Mozilla is to use two meta elements, where there first contains whitespace, and the second contains the empty string: <meta http-equiv="content-language" content=" " /> <meta http-equiv="content-language" content="" /> The final outcome of the META content-language issue complex must make sure that the above is possible, without triggering a warning in conformance checkers.
Bug 9424 suggests a solution which will also solve this bug.
(In reply to comment #0) > In bug 9440 Sorry. Meant bug 9420
EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document: http://dev.w3.org/html5/decision-policy/decision-policy.html Status: Rejected Change Description: no spec change Rationale: We should not change the language just to allow a temporary workaround with no practical value in real pages.
I want to be able ot use HTML5 *now* and in legacy user agents. I also want to be able to use the HTP content-language header. Provided that the algorithm remains as you want it (that oly the first META element counts), then the following, and I cannot see any reason for it to trigger any warning. <meta http-equiv="content-language" content="" /> <meta http-equiv="content-language" content="," /> <meta http-equiv="content-language" content="" />
EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document: http://dev.w3.org/html5/decision-policy/decision-policy.html Status: Rejected Change Description: no spec change Rationale: The reason is that all three of those lines are meaningless, useful only for a very dubious workaround of a bug with the lang="" processing in legacy UAs.
(In reply to comment #5) Of course, I can always use HTML4 and XHTML1. But ... > Status: Rejected > Change Description: no spec change > Rationale: The reason is that all three of those lines are meaningless, All 3 lines? I must make you aware that the empty string is not an error in HTML5. At least not as I and Validator.nu reads the specification. > useful > only for a very dubious workaround of a bug with the lang="" processing in > legacy UAs. Just change your algorithm so that it only looks at the last META, and I can cut it down to only 2 lines. Which means that there would only be one "dubious" line. Please also note that being able to cancel the HTTP header is useful in any user agent that is able to read the HTTP headers. (Currently also coves IE.) To say that it is useless to make sure that authors are able to concel the effect of HTTP, is like saying that it is useless if authors are able to cancel the user agent default stylesheets. Clearly it is useful for authors to be able to take control over as much as possible.
> I must make you aware that the empty string is not an error in > HTML5. At least not as I and Validator.nu reads the specification. The spec says "the content attribute must have a value consisting of a valid BCP 47 language tag" and the empty string (or indeed a string of spaces) is not a valid language tag according to BCP 47. > > useful > > only for a very dubious workaround of a bug with the lang="" processing in > > legacy UAs. > > Just change your algorithm so that it only looks at the last META, and I can > cut it down to only 2 lines. Which means that there would only be one "dubious" > line. The whole use of Content-Language as any kind of hack to work around two bugs (the lack of support for lang="" and the misinterpretation of HTTP's Content-Language header) is dubious. Making it two lines instead of three makes no improvement. > Please also note that being able to cancel the HTTP header is useful in any > user agent that is able to read the HTTP headers. (Currently also coves IE.) You can "cancel" this misuse of the HTTP header using the lang="" attribute. EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document: http://dev.w3.org/html5/decision-policy/decision-policy.html Status: Rejected Change Description: no spec change Rationale: No new information.