background property on HTML element is ignored when a background property is also specified on the BODY element




19 years ago
18 years ago


(Reporter: braden, Assigned: attinasi)


({css1, regression})

css1, regression

Firefox Tracking Flags

(Not tracked)


(Whiteboard: [nsbeta2-], URL)



19 years ago
The background image on this page (set on the HTML element) nolonger appears. It
used to.

Comment 1

19 years ago
I don't see a background image set on that page (maybe I'm not looking in the 
right places), and neither IE nor Moz currently displays one.  Both browsers 
display a colored background (also set in the stylesheet).  Win98 2000 053008.

There's a background image set in css, but I can't figure out the correct 
absolute URL for the image (I keep getting 404 not found errors).  What is the 
absolute URL of the background image that's supposed to load?

I do get a background image under the text "... ellipsis", btw.  

Comment 2

19 years ago
It's in spackle.css. Of course IE doesn't show it; IE (contrary to the specs)
doesn't support setting the background on the HTML element.

The URL to the image is <>.
It's there, so you shouldn't be getting a 404.

And, yes, I'm aware that the background behind "... ellipsis" is working.
Keywords: regression

Comment 3

19 years ago
Reassiging to Kevin for bug triage.
Assignee: clayton → kmcclusk
Reassigning to Don.
Assignee: kmcclusk → dcone

Comment 5

19 years ago
background-image will work on the body (workaround), will look at what is 
happening when specified on the HTML element...
Assignee: dcone → attinasi
Component: Layout → Style System

Comment 6

19 years ago
The CSS2 spec states:

"User agents should observe the following precedence rules to fill in the 
background: if the value of the 'background' property for the HTML element is 
different from 'transparent' then use it, else use the value of the 'background' 
property for the BODY element."

Note that it says *should* and is thus a recommendation, not a requirement.

Also, the CSS2 spec *recommends* that authors specify their background 
properties on the BODY element rather than the HTML element. (see CSS2 14.2)

spackle.css has a background color and image on both the HTML and the BODY 
elements. We are using the one on the BODY rather than the one on the HTML, and 
the background-image property on the body is 'none' hence you are getting no 
background image. 

I'll reword the summary and take ownership of this bug, however it is not likely 
to get fixed soon since we are not actually in conflict with the specification 
and the use of the background property on BOTH the HTML and BODY elements is 

(note that we honor the background property on the HTML element if there is none 
specified on the BODY, the problem is when you have both the BODY will win).

Thanks for pointing out the bug.
OS: Linux → All
Hardware: PC → All
Summary: Background image does not appear → background property on HTML element is ignored when a background property is also specified on the BODY element
Target Milestone: --- → M20
Marc: The business in the CSS spec about BODY->HTML inheritence only applies
when HTML doesn't have a background (i.e., HTML's bg is transparent).

There are already a few bugs open on this issue that you may wish to have a look
at if you are planning on fixing this:
    bug 2285: Backgrounds on BODY and HTML 
   bug 13473: Root element's background should cover the canvas
   bug 35681: Body is sized too wide
There are many test cases here:

Comment 8

19 years ago
Thanks, Ian. From my reading of the spec it is just a recommendation anyway, not 
a requirement. It was my mistake, however, in the re-coding of 
BodyFixupRule::MapStyleInto, to overwrite the HTML background properties with 
the BODY background properties. I'll have to get back to that and take care of 
the case where the HTML has a background property set and the BODY's background 
is set as well.

Comment 9

19 years ago
Mark: You may argue that those particular words in the spec are not a
requirement, but if you choose not to follow them, then you should follow the
normal rules for applying styles to elements. Currently, Mozilla isn't doing
that either, thus it is violating the spec.

Those rules in the spec are there to allow the canvas to take the backgrounds
specified on BODY under some specific circumstances. If Mozilla is using BODY's
background for the canvas under any other circumstances, it's doing something
other than the spec allows for.

Comment 10

19 years ago
This is a CSS1 issue; adding keyword.
Keywords: css1


19 years ago
Blocks: 2285


19 years ago
No longer blocks: 2285


19 years ago
Blocks: 2285

Comment 11

19 years ago
I'm not arguing that we are doing the right thing - in fact I have admitted 
that I introduced this bug when I reworked the code that maps the HTML and BODY 
backgrounds onto the canvas frame. I have every intention to fix that code when 
I can, it is just that the priority is a little bit lower right now. Please bear 
with me, or better yet, take a look at the method BodyFixupRule::MapStyleInto 
and help me out. Thanks.
*** Bug 45456 has been marked as a duplicate of this bug. ***

It would be a shame if nsbeta2 would not correctly render this (famous) test, 
therefore nominating it.
Keywords: nsbeta2

Comment 14

19 years ago
Putting on [nsbeta2-] radar. Not critical to beta2.
Whiteboard: [nsbeta2-]

Comment 15

19 years ago
I'm with Peter. It would be a shame to release a public commercial preview that
breaks the most famous test of standards-compliance around. Can't do anything
about it myself, unfortunately, but I'm adding myself to the cc list anyway.
Keywords: nsbeta3

Comment 16

19 years ago
Patch for this is attached to related bug 2285 - please set your eyes upon it.

Comment 17

19 years ago
Fixed by fixing bug 2285 (same problem, in nsHTMLBodyElement.cpp)

Verifier: please verify that the site now 
matches the reference image.
Last Resolved: 19 years ago
Resolution: --- → FIXED
As per meeting with ChrisD today, taking QA.

VERIFIED FIXED on Win32 commerical 2000072508. Woohoo!
QA Contact: petersen → py8ieh=bugzilla
You need to log in before you can comment on or make changes to this bug.