319729 - background-position for body tag only adheres to current viewport

Status: VERIFIED INVALID

(Core :: Web Painting, defect)

Description

[drew]

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]

Related to bug 243751?

Comment 2

[Adam Guthrie]

*** This bug has been marked as a duplicate of 243751 ***

Comment 3

[Boris Zbarsky [:bzbarsky]]

Actaully, no.  This is not a duplicate.

Comment 4

[Boris Zbarsky [:bzbarsky]]

The body in this case _is_ wider than the viewport, so this is rather odd.  Need a minimal testcase.

Comment 5

[drew]

(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 [:bzbarsky]]

The "this is rather odd" part referred to our rendering, not the web page... ;)

Comment 7

[Martijn Wargers (dead)]

Attachment: background-image for testcases

Comment 8

[Martijn Wargers (dead)]

Attachment: testcase1

This testcase has mime-type text/html.

Comment 9

[Martijn Wargers (dead)]

Attachment: 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 (dead)]

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]

Attachment: 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)]

Note that in text/html documents 'background' properties set on the html:body element get propagated to the viewport.

Comment 13

[drew]

(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 [:bzbarsky]]

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]

Ria can probably help us out with finding the regression range (if any).

Comment 16

[Ria Klaassen (not reading all bugmail)]

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

Comment 17

[Martijn Wargers (dead)]

In that case it would be a regression from bug 241694.

Comment 18

[Boris Zbarsky [:bzbarsky]]

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 [:bzbarsky]]

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-4, no longer working on Mozilla)]

I don't see how that text fixes the problem.

Comment 21

[Boris Zbarsky [:bzbarsky]]

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 [:bzbarsky]]

David, do you still think there's an issue here?

Comment 23

[Anne (:annevk)]

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 [:bzbarsky]]

What's the issue?  We're rendering per the spec here.

Comment 25

[Boris Zbarsky [:bzbarsky]]

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)]

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 [:bzbarsky]]

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)]

It seems that is now bug 590491.