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




CSS Parsing and Computation
7 years ago
6 years ago


(Reporter: Leif Halvard Silli, Unassigned)



Firefox Tracking Flags

(Not tracked)





7 years ago
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

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

Comment 2

7 years ago
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.
Component: DOM → Style System (CSS)
Keywords: html5
QA Contact: general → style-system

Comment 3

7 years ago
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

6 years ago
(In reply to comment #2)

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

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:

(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.
You need to log in before you can comment on or make changes to this bug.