253135 - The Bottom attribute for Absolutely positioned elements is calculated relative to the window, not the page

Status: RESOLVED DUPLICATE of bug 105286

(Core :: CSS Parsing and Computation, defect)

Description

[Robert Goldsmith]

User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-us) AppleWebKit/125.2 (KHTML, like Gecko) Safari/125.8
Build Identifier: 

At the site 'www.far-blue.co.uk' the semi-translucent grey box is an absolutely positioned div with a 
'bottom' attribute set to 20px above the bottom of the page. This seems to render correctly in khtml 
based browsers but Mozilla based browsers calculate this offset from the bottom relative to the original 
window size for the browser (or seem to). As a result, if the div's content is larger than 1 window 
height, it will overflow and a vertical scroll bar will appear but the grey div does no get recalculated.

Reproducible: Always
Steps to Reproduce:
1. Visit www.far-blue.co.uk or, even better, one of the longer pages such as Thoughts-Reasoning Love
2. if needed, resize the browser window so that the content is too deep for the window
3. 
Actual Results:  
The content overflows the grey parent element, which has been calculated based on window or initial 
page height, not final page height.

Expected Results:  
The grey parent element should have grown to accommodate the content and still leave 20px at the 
bottom of the page as specified in the css. You can see what I consider the correct rendering in, for 
instance, Safari

Comment 1

[Christian :Biesinger (don't email me, ping me on IRC)]

the grey box looks exactly the same to me in konqueror and mozilla (linux, but
you marked this all platforms). can you attach a screenshot of the misrendering?
and of how you expect it to look?

Comment 2

[Robert Goldsmith]

Attachment: This is what mozilla does

compare this to the other image, which is from Safari, and look carefully at
the grey background. In Safari it comes right down to the bottom of the page,
in Mozilla, it stops just above the line starting 'Love is essential'

Comment 3

[Robert Goldsmith]

Attachment: how the page should render

compare this to the other image, which is from Mozilla, and look carefully at
the grey background. In Safari it comes right down to the bottom of the page,
in Mozilla, it stops just above the line starting 'Love is essential'

Comment 4

[Boris Zbarsky [:bzbarsky]]

The 20px should be measured from the bottom of the containing block.  Since
there are no positioned ancestors, the containing block for the body is the
initial containing block in CSS2.1 (unlike CSS2.0, where it was the root element).

The initial containing block in Mozilla is the viewport, so the rendering is
correct.

It sounds like the version of khtml you are using is rendering per CSS 2.0...
Please report this to them as a bug.

Comment 5

[Robert Goldsmith]

so you are saying that the root container is no longer the page? So from now on, anyone wishing to 
specify css values relative to the page will have to explicitly code a page-sized root container? And is it 
even possible to do this now? No, that doesn't sound right. The CSS spec only -suggests- the initial cb 
is based on the view port but this behaviour allows an otherwise correctly coded div to allow it's content 
to overspill. I would expect this behaviour from a fixed element (as I expect a fixed element's attributes 
to refer to the viewport, as the css spec requires) but not of an absolute element where I would always 
expect the attributes to refer to the page.

Comment 6

[Mats Palmgren (inactive)]

Isn't this a dupe of bug 105286?

Comment 7

[Boris Zbarsky [:bzbarsky]]

> so you are saying that the root container is no longer the page? 

There is no "the page" in CSS... The initial containing block is indeed distinct
from the box established by the root element in CSS 2.1.

Note that setting the root element to position:relative makes it the containing
block for its positioned descendants, though.

> Isn't this a dupe of bug 105286?

You're right.  It is.

Comment 8

[Boris Zbarsky [:bzbarsky]]

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