CSS background-color with "0" value renders black in Quirks mode (IE renders white)

NEW
Unassigned

Status

()

P4
normal
16 years ago
4 years ago

People

(Reporter: christinehoff4, Unassigned)

Tracking

(Blocks: 1 bug, {dev-doc-needed, testcase})

Trunk
dev-doc-needed, testcase
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [QA-P3], URL)

Attachments

(6 attachments)

(Reporter)

Description

16 years ago
If CSS background-color property is given a value of "0", Netscape renders the
background black (in Quirks mode) and white (in Standards mode). IE renders
background in white. Don't understand why we have this behavior in Quirks.

This problem is showing up on a China topsite (see Url above) with the
background color in input boxes. 

Simplified testcase (with strict doctype) attached using DIVs, demonstrating
same behavior as IT in Standards mode.
(Reporter)

Comment 1

16 years ago
Created attachment 100481 [details]
simplified testcase with strict doctype
(Reporter)

Comment 2

16 years ago
Tested with Netscape 09_05_11 trunk build.
background-color: 000000;

will be black in both us and IE (in quirks mode).  What will

background-color: 000;

do?

The problem is that we parse the "0" as a hex color spec and we parse it as
equivalent to those two specs...
Does anybody know exactly how IE is behaving when given color specs with
incorrect numbers of digits or containing non-hex characters?  (Also, any
differences based on the presence or absence of #?)  Our quirk-mode color
parsing should just be an imitation of IE -- otherwise there's not much point. 
(And does the web really need it?  Maybe we should just remove it.)
I don't know the exact behavior, though I spent a few days once trying to narrow
it down... further, I don't know whether they use the same parser for HTML
attributes and CSS values (which is what we do).  I know that in HTML attributes
we parse strings with over 6 chars differently from IE (and differently from NS4
too, I should note; IE and NS4 agree).

I would agree with restricting our CSS quirk to "inserting" the missing '#',
though, and dropping values like "0" and "00" (but not "000", of course).

Comment 6

16 years ago
Just to add some confusion... IE 5.1.2 for Mac OS X renders the testcase as
white. However, removing the doctype (quirks mode) will make the div green!

Furthermore: 00 = white, 000 = black, 0000 = white, 00000 = 000000 = black.

f = green, ff = fff = ffff = white, fffff = light-yellow, ffffff = white

Ignorance is truly bliss.

Comment 7

16 years ago
Created attachment 100728 [details]
in Quirks mode --- no doctype

this testcase shows the behaviour of background-color with various values :
0 ==> black
00 ==> black 
000 ==> black
0000 ==> black
00000 ==> black
000000 ==> black
#0 ==> white
#00 ==> white
#000 ==> black
#0000 ==> white
#00000 ==> white
#000000 ==> black

Comment 8

16 years ago
Created attachment 100729 [details]
in Standards Mode

this testcase shows the behaviour of background-color with various values :
0 ==> white
00 ==> white
000 ==> white
0000 ==> white
00000 ==> white
000000 ==> white
#0 ==> white
#00 ==> white
#000 ==> black
#0000 ==> white
#00000 ==> white
#000000 ==> black

Comment 9

16 years ago
setting QA priority to [QA-P3] based on 
"severity * visibility"
Visibilty is 'high' since this has been detected on a Chine Topsite --
http://news.szptt.net.cn/ 
Severity is 'low' since it is a cosmetic issue
Keywords: testcase
Whiteboard: [QA-P3]
The non-black backgrounds are NOT white, they're transparent, which is what the
default should be (any unrecognized value should be ignored, so the default
value is used).  Thus the results shown above should actually read:

Quirks mode --- no doctype:
0 ==> black
00 ==> black 
000 ==> black
0000 ==> black
00000 ==> black
000000 ==> black
#0 ==> transparent
#00 ==> transparent
#000 ==> black
#0000 ==> transparent
#00000 ==> transparent
#000000 ==> black

Standards mode:
0 ==> transparent
00 ==> transparent
000 ==> transparent
0000 ==> transparent
00000 ==> transparent
000000 ==> transparent
#0 ==> transparent
#00 ==> transparent
#000 ==> black
#0000 ==> transparent
#00000 ==> transparent
#000000 ==> black
Created attachment 100738 [details]
dbaron's big testcase - standards mode
Created attachment 100739 [details]
dbaron's big testcase - quirks mode

Comment 13

16 years ago
Thanks for the correction, Eric :-)

Comment 14

16 years ago
more of the same http://bugzilla.mozilla.org/show_bug.cgi?id=197357
Someone needs to answer David's question from comment 4....
Keywords: qawanted
Assignee: dbaron → nobody
QA Contact: ian → style-system
We probably want to consider removing some quirks here.

See also bug 121738 (for HTML).
OS: Windows 2000 → All
Priority: -- → P4
Hardware: x86 → All

Comment 17

5 years ago
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:26.0) Gecko/20100101 Firefox/26.0

All the attached testcases work as in IE10, except for some cases in "dbaron's big testcase - quirks mode". They don't always display black instead of white, it's also red, green or blue sometimes.

Here are the problematic cases in that testcase:
    <td style="background-color: 0F">
    <td style="background-color: 0F0">
    <td style="background-color: 0F00">
    <td style="background-color: 0F000">
    <td style="background-color: 0F0000">
    <td style="background-color: 0F000000">
    <td style="background-color: 00F">
    <td style="background-color: 00F0">
    <td style="background-color: 00F00">
    <td style="background-color: 00F00000">
    <td style="background-color: 000F">
    <td style="background-color: 000F0">
    <td style="background-color: 000F00">
    <td style="background-color: 000F000">
    <td style="background-color: 000F0000">
    <td style="background-color: 000F00000">
    <td style="background-color: 0000F">
    <td style="background-color: 0000F000">
    <td style="background-color: 0000F0000">
    <td style="background-color: 00000F0">
    <td style="background-color: 00000F00">
    <td style="background-color: 00000F000">
    <td style="background-color: 000000F">
    <td style="background-color: 000000F0">
    <td style="background-color: 000000F00">
    <td style="background-color: 0000000F">
    <td style="background-color: 0000000F0">
    <td style="background-color: 00000000F">
Keywords: qawanted

Comment 18

5 years ago
Created attachment 794026 [details]
Testcase with quirks in Firefox, Chrome and IE
Summary: background-color with "0" value renders black in Quirks mode (IE renders white) → CSS background-color with "0" value renders black in Quirks mode (IE renders white)

Comment 19

5 years ago
Spec: http://quirks.spec.whatwg.org/#the-hashless-hex-color-quirk
Tests: http://w3c-test.org/quirks-mode/hashless-hex-color.html (these quirks tests are now in web-platform-tests)

Comment 20

4 years ago
Data: http://webdevdata.org data set 2013-09-01 102,000 pages.

$ find . -type f -print0 | xargs -0 -P 4 -n 40 grep -iEo "color\s*:\s*([0-9a-f]{1,2}|[0-9a-f]{4,5}|[0-9a-f]{7,})(\s|\"|\'|;|$)" >> ../hashless-wrong-length.txt

Most of the matches aren't in quirks mode to begin with. I found three sites with observable difference.

Effect of the moz/blink/webkit behavior:

blackbarbara.com and amandapics.com (porn sites)
The links at the top next to "Archived pages:" is black on hover.
a.arch:hover { ... color: 0;

http://www.worldfreeads.com/index.php?a=10&b[username]=x
The form error message is green instead of black.
.login_form_error { ... color: 88000;

For these pages, it seems moz/blink/webkit behavior is closer to author intent than the IE behavior. But there were so few matches that we can do whatever. Things could be different if looking at the long tail Web or external stylesheets, though. Unless there is data to the contrary, I think it makes sense to align the spec with moz/blink/webkit instead of IE. It also avoids using the "representation" for this quirk.

Comment 21

4 years ago
I forgot that three-characer colors are also relevant (when they are number or dimension).

It seems more likely that they intended the IE behavior. But this was also rare.

http://www.wpthemes360.com color:111
http://www.shortnews.de color:333

For these pages the difference is not clearly visible since the colors are so dark.

http://a4esl.org color:666; color:555

I couldn't see any difference in rendering for this page.

Comment 22

4 years ago
Another problem I noticed now is scientific notation. I actually only found one page with different rendering.

http://thegame.org/ color:208e2a
Currently Gecko makes this rgb(32, 128, 10) while #208e2a is rgb(32, 142, 42). In this case that's close enough but in other cases it could be way off, e.g. 9e9e9e or 40e10a, or it can drop the declaration if the number is too large e.g. 9e100a.

Gecko drops the declaration when scientific notation is used as a number rather than a dimension, e.g. 1111e1.

It seems saner to consistently drop the declaration here.
Keywords: dev-doc-needed
You need to log in before you can comment on or make changes to this bug.