Closed Bug 319729 Opened 19 years ago Closed 14 years ago

background-position for body tag only adheres to current viewport


(Core :: Web Painting, defect)

1.8 Branch
Windows XP
Not set





(Reporter: drew.covi, Assigned: dbaron)




(Keywords: qawanted)


(4 files)

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8) Gecko/20051111 Firefox/1.5
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8) Gecko/20051111 Firefox/1.5

under proper css, the background-position for the body tag should force the blue box on the right to adhere to the far right of the body rather than simply the right hand side of the viewport. viewed properly, the box should fall under the navigation at the end of the page.

although uncommon today, horizontal pages like this should be an option to web designers.

Reproducible: Always

Steps to Reproduce:
1. visit said site
Actual Results:  
css background property for the body tag is applied to the viewport not the actual  body.

Expected Results:  
light blue background should be at far right of layout, not far right of screen.
Assignee: nobody → dbaron
Component: General → Style System (CSS)
Product: Firefox → Core
QA Contact: general → ian
Version: unspecified → 1.8 Branch
Related to bug 243751?

*** This bug has been marked as a duplicate of 243751 ***
Closed: 19 years ago
Resolution: --- → DUPLICATE
Actaully, no.  This is not a duplicate.
Resolution: DUPLICATE → ---
The body in this case _is_ wider than the viewport, so this is rather odd.  Need a minimal testcase.
Keywords: qawanted
(In reply to comment #4)
> The body in this case _is_ wider than the viewport, so this is rather odd. 
> Need a minimal testcase.

agreed, its atypical, however its a fascinating design. similar layouts should be available to change things up in the future. minimal test case soon to come unless someone beats me to it.
The "this is rather odd" part referred to our rendering, not the web page... ;)
Attached file testcase1
This testcase has mime-type text/html.
Attached file testcase2
This is the same as testcase1, but with application xml/xhtml+xml (or something like that).

So it seems to me that we have the situation as mentioned here:
For HTML documents, however, we recommend that authors specify the background for the BODY element rather than the HTML element. For HTML documents whose root HTML element has computed values of 'transparent' for 'background-color' and 'none' for 'background-image', user agents must instead use the computed value of those properties from that HTML element's first BODY element child when painting backgrounds for the canvas, and must not paint a background for that BODY element. This does not apply to XHTML documents.

Css Zen garden serves it's document as text/html, so I think this bug is invalid.
Oh, testcase2 doesn't render a horizontal scrollbar, that happens because the body has a height of 0px so the testcase acts a bit strange, but acts correctly in Mozilla, I believe.
granted im new to the whole bug reporting system, but i just added a height for the last test case, so you could compare what should occur with what should...
Note that in text/html documents 'background' properties set on the html:body element get propagated to the viewport.
(In reply to comment #12)
> Note that in text/html documents 'background' properties set on the html:body
> element get propagated to the viewport.
Shouldn't it propegate only if the background property is set to fixed?
So... the fact that the body height affects the rendering is really odd.  I can try to figure out whether this is a regression (and if so, when it regressed) when I get back, but it seems like we're just putting the background in the wrong place (certainly so in the XHTML case).
Component: Style System (CSS) → Layout: View Rendering
Ria can probably help us out with finding the regression range (if any).
In that case it would be a regression from bug 241694.
OK, now that I'm actually in possession of a reasonable net connection and browser I see what's going on here.  The problem is that the correct behavior is not actually defined in the CSS spec.  See my request for clarification from the CSS Working Group from about a year ago (

The "just as testcase2 but with a height so the scrollbar appears" testcase is NOT just like testcase 2, since it has a different MIME type.  If I change the type to application/xhtml+xml (from the current text/html), then the positioning of the background does not in fact depend on the height (as expected).

So depending on the CSS WG either this bug is invalid or we need to change where our body background is anchored when we propagate it to the canvas.
Attachment #206165 - Attachment mime type: text/html → application/xhtml+xml
Ah, ok.  So I was misremembering what the spec said; it's been updated and the current text is what Martijn cites in comment 9.  Per that text, this bug is invalid.

See also bug 285183 which is basically the same issue.
Closed: 19 years ago19 years ago
Depends on: 285183
Resolution: --- → INVALID
I don't see how that text fixes the problem.
Resolution: INVALID → ---
Per that text, the box generated by the root element is used for background-positioning purposes, no?

That's the intent, per mail from Ian about a year ago; if it's still not clear we should re-raise this with the WG (retract the retraction I sent today).
David, do you still think there's an issue here?
QA Contact: ian → layout.view-rendering seems like this is still an issue. (Though not really specific to <body>.)
What's the issue?  We're rendering per the spec here.
Closed: 19 years ago14 years ago
Resolution: --- → INVALID
To be clear, "issue" in comment 22 was about whether the spec text is clear enough, not about whether our behavior matches what the spec means to say.
It seems the problem is that in Gecko the root element stretches to contain the float. But I guess that is a separate bug from aligning with respect to the root element as that happens.
It looks like if the document element is a block we make it a block formatting context root.  Then CSS 2.1 section 10.6.7 last paragraph kicks in.

It's not clear to me whether we need to make it a formatting context root...  But yes, that's a separate issue.
It seems that is now bug 590491.
Component: Layout: View Rendering → Layout: Web Painting
You need to log in before you can comment on or make changes to this bug.