564290 - Make sure that fallback from Content-Language does not override lang="<emptystring>"

Status: UNCONFIRMED

(Core :: CSS Parsing and Computation, defect)

Description

[Leif Halvard Silli]

User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10_5_8; nn-no) AppleWebKit/531.22.7 (KHTML, like Gecko) iCab/4.7 Safari/525.27.1
Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.3a2pre) Gecko/20100217 Minefield/3.7a2pre

HTML5 defines lang="<theEmptyString>" to have the same meaning as xml:lang="<theEmptyString>". Namely, it explicitly sets the language of the element to unknown.

Geck does already behave like this. *Except* when a fallback language from Content-Language kicks in. Then the language from Content-Language will override the the empty string.

Reproducible: Always

Steps to Reproduce:
1.  Visit a page without any lang="" attribute, except empty lang attributes
      <div lang="">....</div>
2. Make sure the page has a Content-Language HTTP header or META element.
     The value of Content-Language  should be "en".
3. Create a CSS style with the "impossible"/illogical selector 
     div[lang=""]:lang(en) {background:red}
4. Test in a browser. 
Actual Results:  
The element will be colored red.

Expected Results:  
The CSS selector should not work, because the element actually doesn't have any lanuage set.

Comment 1

[Leif Halvard Silli]

The bug kicks in both in XHTML (application/xhtml+xml) and in text/html.

Comment 2

[Boris Zbarsky [:bzbarsky]]

Not a DOM issue; this is pure CSS code.  We can change this pretty easily, but I don't think it's worth doing that until the spec is actually considered stable.

Comment 3

[Leif Halvard Silli]

But is the current behaviour based on any spec? 

In HTML4 and XHTML 1.0, then the empty string is simply forbidden. But still, even if it is forbidden, it should not be ignored, any more than illegal tags should be ignored.

Thus in my view, it is safe to change this now - there is no clear link to HTML5/XHTML5 here. The only link is that HTML5/XHTML5 makes it permitted to use the emtpy string and also defines what it means.

Comment 4

[Leif Halvard Silli]

(In reply to comment #2)

The HTMLwg has made the http-equiv='Content-Language' *meta element* non-conforming in HTML5.

http://lists.w3.org/Archives/Public/public-html/2011Mar/0398.html

Boris, does this make the spec more stable, in your eyes?

Btw, would it 'break the Web' if Firefox *stopped* inheriting a language from the HTTP Content Language: *header*, like I suggested here: 
http://www.w3.org/mid/[e-mail]
??

(It seems OK if the http-equiv='Content-Language' *meta element* has effect, since it is actually forbidden and since it is rather uniformly supported. However, the HTTP Content-Language: header only works in Firefox and IE and thus is not likely to affect "the Web" very much.