W3C home > Mailing lists > Public > public-html-bugzilla@w3.org > March 2010

[Bug 9264] New: Provide a way to prevent Content-Language from acting as language fallback

From: <bugzilla@wiggum.w3.org>
Date: Thu, 18 Mar 2010 11:36:07 +0000
To: public-html-bugzilla@w3.org
Message-ID: <bug-9264-2486@http.www.w3.org/Bugs/Public/>
http://www.w3.org/Bugs/Public/show_bug.cgi?id=9264

           Summary: Provide a way to prevent Content-Language from acting as
                    language fallback
           Product: HTML WG
           Version: unspecified
          Platform: PC
               URL: http://dev.w3.org/html5/spec/semantics.html#pragma-
                    directives
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: HTML5 spec bugs
        AssignedTo: dave.null@w3.org
        ReportedBy: xn--mlform-iua@xn--mlform-iua.no
         QAContact: public-html-bugzilla@w3.org
                CC: ian@hixie.ch, mike@w3.org, public-html@w3.org


Challenge: When a node's language is set to "unknown" via an empty lang=""
attribute, then user agents should respect that and not search for a fallback
language in a META@content-language and/or the content-language header from the
server. (See Bug 9263)

HOWEVER,  there is a practical problem: Firefox and Safari (Gecko and Webkit)
currently break this rule, and instead applies any language tag they may find
in the content-language HTTP header/META element as the language of such
elements.

Test case:  http://software.hixie.ch/utilities/js/live-dom-viewer/saved/406

For Webkit, Konqueror and Chrome, the cure for this is to provide two (2) META
elements - one who defines the content-language(s) and then an empty one:

<!DOCTYPE html>
<html  lang="">
<meta http-equiv="Content-Language" content="en">
<meta http-equiv="Content-Language" content="">
<p>Webkit, Konqueror and Chrome think the language is unknown here.

Test case: http://software.hixie.ch/utilities/js/live-dom-viewer/saved/407

However, this doesn't cure it for Mozilla browsers. Firstly, they don't care
whether the empty META comes first or last. But they do require that the empty
META contains white-space!

<!DOCTYPE html>
<html  lang="">
<meta http-equiv="Content-Language" content="en">
<meta http-equiv="Content-Language" content="                                
">
<p>Mozilla browsers think the language is unknown here.

Test case: http://software.hixie.ch/utilities/js/live-dom-viewer/saved/408

The problem is that this is invalid in the current version of HTML5.

In HTML4 and XHTML, there is no requirement that the content="" attribute of
the <META> Content-Language element doesn't contain only white-space.

But HTML5 says that it is the *first* META pragma that defines the language.
The second META should be ignored.

PROPOSAL: 

Variant 1: As long as the documentís *first* <META> Content-Language element
fulfills the HTML5 requirements (whatever they will end up looking like), then
the next/last <META> Content-Language element should be allowed to have content
which cancels the fallback language effect. Namely, it should be allowed to
contain white-space. (Or a comma - or something else that works.) 

Variant 2: A <META> Content-Language element  should be allowed to contain
whitespace. (Or a comma - or something else that cancels the fallback language
effect.)


-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
Received on Thursday, 18 March 2010 11:36:12 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 18 March 2010 11:36:18 GMT