451 bytes, image/jpeg
541 bytes, text/html
541 bytes, application/xhtml+xml
527 bytes, application/xhtml+xml
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.
Related to bug 243751?
*** This bug has been marked as a duplicate of 243751 ***
Actaully, no. This is not a duplicate.
The body in this case _is_ wider than the viewport, so this is rather odd. Need a minimal testcase.
(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 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.
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...
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).
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.
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.
I don't see how that text fixes the problem.
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?
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.
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.