Last Comment Bug 564290 - Make sure that fallback from Content-Language does not override lang="<emptystring>"
: Make sure that fallback from Content-Language does not override lang="<emptys...
: html5
Product: Core
Classification: Components
Component: CSS Parsing and Computation (show other bugs)
: unspecified
: All All
-- normal (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
: Jet Villegas (:jet)
Depends on:
  Show dependency treegraph
Reported: 2010-05-06 14:13 PDT by Leif Halvard Silli
Modified: 2011-03-19 09:51 PDT (History)
1 user (show)
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Description User image Leif Halvard Silli 2010-05-06 14:13:19 PDT
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 User image Leif Halvard Silli 2010-05-06 14:14:16 PDT
The bug kicks in both in XHTML (application/xhtml+xml) and in text/html.
Comment 2 User image Boris Zbarsky [:bz] (still a bit busy) 2010-05-06 20:14:07 PDT
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 User image Leif Halvard Silli 2010-05-07 19:05:40 PDT
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 User image Leif Halvard Silli 2011-03-19 09:51:12 PDT
(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.

Note You need to log in before you can comment on or make changes to this bug.