The default bug view has changed. See this FAQ.

background-position for body tag only adheres to current viewport

VERIFIED INVALID

Status

()

Core
Layout: View Rendering
VERIFIED INVALID
11 years ago
7 years ago

People

(Reporter: drew, Assigned: dbaron)

Tracking

({qawanted})

1.8 Branch
x86
Windows XP
qawanted
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(4 attachments)

(Reporter)

Description

11 years ago
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.

Updated

11 years ago
Assignee: nobody → dbaron
Component: General → Style System (CSS)
Product: Firefox → Core
QA Contact: general → ian
Version: unspecified → 1.8 Branch

Comment 1

11 years ago
Related to bug 243751?

Comment 2

11 years ago

*** This bug has been marked as a duplicate of 243751 ***
Status: UNCONFIRMED → RESOLVED
Last Resolved: 11 years ago
Resolution: --- → DUPLICATE
Actaully, no.  This is not a duplicate.
Status: RESOLVED → UNCONFIRMED
Resolution: DUPLICATE → ---
The body in this case _is_ wider than the viewport, so this is rather odd.  Need a minimal testcase.
Keywords: qawanted
(Reporter)

Comment 5

11 years ago
(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... ;)
Created attachment 205909 [details]
background-image for testcases
Created attachment 205910 [details]
testcase1

This testcase has mime-type text/html.
Created attachment 205912 [details]
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:
http://www.w3.org/TR/CSS21/colors.html#q2
"
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.
(Reporter)

Comment 11

11 years ago
Created attachment 206165 [details]
just as testcase2 but with a height so the scrollbar appears

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...

Comment 12

11 years ago
Note that in text/html documents 'background' properties set on the html:body element get propagated to the viewport.
(Reporter)

Comment 13

11 years ago
(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

Comment 15

11 years ago
Ria can probably help us out with finding the regression range (if any).
These are antique builds: 2004-04-30 09 - 2004-05-02 09. 

http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=PhoenixTinderbox&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2004-04-30+08%3A00%3A00&maxdate=2004-05-02+09%3A00%3A00&cvsroot=%2Fcvsroot


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 (http://lists.w3.org/Archives/Public/www-style/2005Mar/0056).

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.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 11 years ago11 years ago
Depends on: 285183
Resolution: --- → INVALID
(Assignee)

Comment 20

11 years ago
I don't see how that text fixes the problem.
Status: RESOLVED → UNCONFIRMED
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

Comment 23

7 years ago
http://software.hixie.ch/utilities/js/live-dom-viewer/saved/596 seems like this is still an issue. (Though not really specific to <body>.)
What's the issue?  We're rendering per the spec here.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 11 years ago7 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.

Comment 26

7 years ago
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.

Comment 28

7 years ago
It seems that is now bug 590491.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.