Last Comment Bug 319729 - background-position for body tag only adheres to current viewport
: background-position for body tag only adheres to current viewport
Status: VERIFIED INVALID
: qawanted
Product: Core
Classification: Components
Component: Layout: View Rendering (show other bugs)
: 1.8 Branch
: x86 Windows XP
: -- normal (vote)
: ---
Assigned To: David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch)
:
Mentors:
http://www.csszengarden.com/?cssfile=...
Depends on: 285183
Blocks:
  Show dependency treegraph
 
Reported: 2005-12-09 13:13 PST by drew
Modified: 2010-08-26 01:07 PDT (History)
7 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
background-image for testcases (451 bytes, image/jpeg)
2005-12-14 17:26 PST, Martijn Wargers [:mwargers] (gone per 2016-05-31 :-( )
no flags Details
testcase1 (541 bytes, text/html)
2005-12-14 17:29 PST, Martijn Wargers [:mwargers] (gone per 2016-05-31 :-( )
no flags Details
testcase2 (541 bytes, application/xhtml+xml)
2005-12-14 17:32 PST, Martijn Wargers [:mwargers] (gone per 2016-05-31 :-( )
no flags Details
just as testcase2 but with a height so the scrollbar appears (527 bytes, application/xhtml+xml)
2005-12-17 00:13 PST, drew
no flags Details

Description drew 2005-12-09 13:13:04 PST
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.
Comment 1 zug_treno 2005-12-10 09:03:04 PST
Related to bug 243751?
Comment 2 Adam Guthrie 2005-12-10 16:11:38 PST

*** This bug has been marked as a duplicate of 243751 ***
Comment 3 Boris Zbarsky [:bz] 2005-12-11 07:10:33 PST
Actaully, no.  This is not a duplicate.
Comment 4 Boris Zbarsky [:bz] 2005-12-11 07:11:55 PST
The body in this case _is_ wider than the viewport, so this is rather odd.  Need a minimal testcase.
Comment 5 drew 2005-12-11 10:07:43 PST
(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.
Comment 6 Boris Zbarsky [:bz] 2005-12-11 10:21:45 PST
The "this is rather odd" part referred to our rendering, not the web page... ;)
Comment 7 Martijn Wargers [:mwargers] (gone per 2016-05-31 :-( ) 2005-12-14 17:26:33 PST
Created attachment 205909 [details]
background-image for testcases
Comment 8 Martijn Wargers [:mwargers] (gone per 2016-05-31 :-( ) 2005-12-14 17:29:32 PST
Created attachment 205910 [details]
testcase1

This testcase has mime-type text/html.
Comment 9 Martijn Wargers [:mwargers] (gone per 2016-05-31 :-( ) 2005-12-14 17:32:51 PST
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.
Comment 10 Martijn Wargers [:mwargers] (gone per 2016-05-31 :-( ) 2005-12-14 17:36:44 PST
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.
Comment 11 drew 2005-12-17 00:13:09 PST
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 Anne (:annevk) 2005-12-17 10:53:58 PST
Note that in text/html documents 'background' properties set on the html:body element get propagated to the viewport.
Comment 13 drew 2005-12-19 11:00:23 PST
(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?
Comment 14 Boris Zbarsky [:bz] 2005-12-23 10:51:10 PST
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).
Comment 15 Adam Guthrie 2005-12-23 12:14:20 PST
Ria can probably help us out with finding the regression range (if any).
Comment 17 Martijn Wargers [:mwargers] (gone per 2016-05-31 :-( ) 2005-12-23 13:14:09 PST
In that case it would be a regression from bug 241694.
Comment 18 Boris Zbarsky [:bz] 2006-03-14 13:10:30 PST
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.
Comment 19 Boris Zbarsky [:bz] 2006-03-14 13:18:14 PST
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.
Comment 20 David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch) 2006-03-14 14:33:25 PST
I don't see how that text fixes the problem.
Comment 21 Boris Zbarsky [:bz] 2006-03-14 15:05:24 PST
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).
Comment 22 Boris Zbarsky [:bz] 2007-03-29 14:54:06 PDT
David, do you still think there's an issue here?
Comment 23 Anne (:annevk) 2010-08-24 08:45:17 PDT
http://software.hixie.ch/utilities/js/live-dom-viewer/saved/596 seems like this is still an issue. (Though not really specific to <body>.)
Comment 24 Boris Zbarsky [:bz] 2010-08-25 00:16:26 PDT
What's the issue?  We're rendering per the spec here.
Comment 25 Boris Zbarsky [:bz] 2010-08-25 00:17:03 PDT
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 Anne (:annevk) 2010-08-25 00:35:38 PDT
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.
Comment 27 Boris Zbarsky [:bz] 2010-08-25 01:00:18 PDT
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 Anne (:annevk) 2010-08-26 01:07:06 PDT
It seems that is now bug 590491.

Note You need to log in before you can comment on or make changes to this bug.