Closed Bug 227072 Opened 19 years ago Closed 13 years ago

bgcolor transparent is blue in quirks mode => should be white


(Core :: CSS Parsing and Computation, defect)

Not set





(Reporter: gaemon, Assigned: dbaron)




(Keywords: compat, testcase)


(2 files, 1 obsolete file)

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6b) Gecko/20031128
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6b) Gecko/20031128

quirks mode renders elements with bgcolor=transparent attribute as blue.
standard mode is rendered as expected.

Reproducible: Always

Steps to Reproduce:
1. create an html without doctype declaration.
2. set bgcolor=transparent to any element: e. g. <body>

Actual Results:  
background of the element becomes blue. is the same file except the DOCTYPE
declaration. it is rendered white.

Probably for backwards compatibility with Netscape4.x, which also renders it as

You know you should use style sheets for this, do you? - doesn't say
anything about transparency except one thing relating to table borders. Nothing
in quirks.css, either. So _is_ it maybe a bug? Someone with Nav4 want to check this?

Since I'm on Linux, updating the OS, etc. but not confirming since I don't know
if it's a bug or not.
Assignee: win32 → general
Severity: normal → minor
Component: GFX: Win32 → GFX
OS: Windows XP → All
As I said in comment 1, NN4 renders it the same way in quirks mode (=blue).
Oh, whoops, I missed that. Then should this be resolved as invalid or morphed
into "put a notice of that on the quirks mode page"? Or alternately, should it
be morphed into "remove that quirk" since quirks is for compatibility and the
90% that use IE won't see it as blue either, plus it probably takes up (a tiny
bit of) code size and rendering time?
Since NN4 has a user-base of 0 (1%) and it is not likely that there are sites
out there, which still rely on this bug (IE does it different) this should be

(off-topic:  thanks for the link to the mozilla specifications)
Component: GFX → Style System (CSS)
Ever confirmed: true
Summary: bgcolor transparent becomes blue in quirks mode → bgcolor transparent is blue in quirks mode => should be white
"transparent" gives a DOM value of "#0000e0"

Duplicate of bug 121738 or bug 204826?
Assignee: general → dbaron
Keywords: testcase
Since it is not about the color that is 'shown', it is about the keyword
(transparant) that gives a different 'view' than you would expect (white instead
of blue).

*** This bug has been marked as a duplicate of 204826 ***
Closed: 19 years ago
Resolution: --- → DUPLICATE
I intentionally left this bug unresolved because I wanted the module owner to
decide if it is a WONTFIX or not.

Although "transparent" is not a color name, it is a valid value for the CSS
property 'background-color' and I felt it could be worth considering if it also
makes us compatible with IE.
Keywords: compat, qawanted
Resolution: DUPLICATE → ---
Is it white in IE/Windows because IE/Windows is interpreting transparent
specially or because the backwards-compatible color name handling algorithm
makes transparent white?
I tested in IE: <table bgcolor="yellow"><td bgcolor="transparent">text...
The cell bg was yellow and getAttribute('bgcolor') returned "transparent".
If I set bgcolor to "whatever" I got a "#....." hex value from getAttribute -
so it seems they treat "transparent" specially.
Attached file Testcase #1
Attached patch Patch rev. 1 (obsolete) — Splinter Review
If we want to fix it, it should be something like this...
ew, that's a horrible way of fixing it.

Instead of the way Mozilla is doing this now. We could add a Mozilla CSS value,
which will also be in CSS3 (there isn't any CSS3 recommendation...).



 background-color: -moz-attr(bgcolor,color);

This would also give back the result as the author of such document would expect
it. This -moz-attr() could also be used for other things, which are currently
done without CSS. Though it is not a saver for everyting, like for the 'alink'
That also doesn't handle the rules on specificity of presentational hints in markup.
Ian, why is that a "horrible" way to fix it, exactly?
Because it gives special magical meaning to a type that happens to be otherwise
unused at that point. For someone reading the code, it appears highly magical.

My preferred fix for this would be to simply treat "transparent" as a normal
colour value that happens to map to rgba(0,0,0,0), and remove any special coding
for that value anywhere. (This may temporarily, until we implement rgba() for
real, require that we special case the alpha=0 case when painting, though. Or we
could simply replace all the current places that special case transparent for
cases that special case alpha=0.)
*** Bug 232537 has been marked as a duplicate of this bug. ***
One thing I noticed is that when one edits the value of bgcolor using the
dominspector you'll see some strange results. Most of the times it will show the
color you've entered, but in some cases if you enter #000000 it will convert
that to #00e000 instead. I don't know if it is related to this...
*** Bug 235387 has been marked as a duplicate of this bug. ***
*** Bug 243350 has been marked as a duplicate of this bug. ***
Hi Developers,
you have the same problem in tables and table-cells. Gecko (Firefox 1.0 PR and 
Firefox 0.9.3) renders <table bgcolor="transparent"> and/or <td 
bgcolor="transparent"> in ugly dark-blue.
I guess bgcolor="transparent" ist not W3C-compliant, although many website use 
these attributes. IE 5.5 or IE 6.0 display white table- or cells-background, so 
Gecko should do it, too.

Best Regards
*** Bug 282726 has been marked as a duplicate of this bug. ***
I'm getting this in FireFox 1.0.4 with content pasted in from Word.  We have a
bunch of tables in Word that when pasted as html include bgcolor="transparent"
in some of the td elements.  As per this issue they table cells are rendering as
blue in FF but okay in IE.  So I have new content running into an old bug.  Yuck.
In my case I was able to add a doctype declaration to the page that renders the
content - as the page now renders in standards compliance mode the "transparent"
background no longer renders as blue.

Dear Developers,
please refer to the comment #22; I share the same concern since I still have the very same problem with:
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv: Gecko/20060728 Firefox/
Could you please advise if and when this could be fixed?

Thanks and best regards.
*** Bug 354961 has been marked as a duplicate of this bug. ***
I got a similar case:

1.Open browser
2.Go to page
3.Notice the background under page menu (on right side)

Background image is displayed.

Background image is not displayed. Menu is in Flash and looks like it's
transparent - but here it is not displayed as transparent but as with white
background - that may be cause why background image is not displayed as on
desktop. See attached screenshots.

Assignee: dbaron → nobody
QA Contact: ian → style-system
Duplicate of this bug: 400911
One important detail must be understood. 99% or so of all MSIE users have background color set by default to white. But if I have it set to, say, light green, then <body bgcolor="transparent" ...> will render a light green background-color, NOT white color.
> Is it white in IE/Windows because IE/Windows is interpreting transparent
> specially or because the backwards-compatible color name handling algorithm
> makes transparent white?

It is white in IE/Windows because IE/Windows setting 
Tools/Internet Options.../General tab/Colors/Background is set to white color or because Tools/Internet Options.../General tab/Colors/Background "Use Windows colors" checkbox is checked. MSIE 7 under XP Pro here.
Depends on: 555122
According to HTML5, 'transparent' should be rejected.  (See bug 121738.)
Assignee: nobody → dbaron
Attachment #136533 - Attachment is obsolete: true
Attachment #446915 - Flags: review?(jonas)
Closed: 19 years ago13 years ago
Keywords: qawanted
Hardware: x86 → All
Resolution: --- → FIXED
Target Milestone: --- → mozilla1.9.3a5
You need to log in before you can comment on or make changes to this bug.