Closed Bug 196937 Opened 21 years ago Closed 17 years ago

position: absolute, bottom: npx initially calculated from bottom of viewport rather than containing block (body element)

Categories

(Core :: Layout: Positioned, defect)

defect
Not set
normal

Tracking

()

RESOLVED INVALID

People

(Reporter: ajp+mozilla, Unassigned)

References

Details

(Keywords: testcase)

Attachments

(6 files)

Load attachment, then resize the window until the bottom is higher than the
middle text.
When a group of text is specified as position: absolute and with a bottom:
position, it always shows up relative to the browser window, not the browser
page, exhibiting the same behavior as position: fixed. I'm not quite sure if
this is the correct behavior according to CSS spec, but AFAIK internet explorer
 exhibits what would seem the be the correct behavior, which is having position:
absolute be from the entire page, not just the window.
By contrast, making a table with height=100% exhibits behavior like IE's for
this bug. Meaning that if the window is bigger than the total page size, the
cell at the bottom will be displayed at the very bottom of the window, or
otherwise at the bottom of the page. In Mozilla, there doesn't seem to be a
proper CSS equivalent of table height=100%.
Attached file testcase #1
while it does appear to be positioning the element to the bottom of the viewport
the element also seems to scroll with the page. I'll attach my strict mode
testcase in a few after i validate it and such
OS: Linux → All
Hardware: PC → All
Ah, I forgot to note that. The fact that it scrolls with the page makes it even
less usable than position: fixed, as if that group of absolute text is placed
over some important content, the content below is basically unusable.
Attached file strict testcase
two things to note with this testcase (best viewed at a browser height
resulting in scrollbars:

(1) position: absolute; bottom: 10px; is positioning the item based on the
viewport and not the body nor the html element however unlike position: fixed;
bottom: 10px it scrolls with the document.

(2) position: absolute; top: 10px; may actually be following the same logic to
position itself initially but because top of viewport == top of html element
(== top of body in non-strict cases) the end result is ok.
Resummarizing slightly (I think it's accurate). ouch...
Keywords: testcase
Summary: position: absolute has same behavior as position:fixed when bottom is specified → position: absolute, bottom: npx initially calculated from bottom of viewport rather than containing block (body element)
bz, is this be a dupe of bug 105286?
More or less, but I'd like to keep it separate for now....
Depends on: 105286
Note that this bug is not a bug as far as I can tell per the CSS2.1 positioning
rules... (since the initial containing block is not the <html> block but rather
the viewport or other UA-dependent box).
Hm, I'm not actually sure about my original statement that this works fine on IE
- could someone with IE confirm or deny that it doesn't work the same way as in
Mozilla?
If this is not a bug per CSS2.1, how would I go about writing a document that
did position something at the bottom of the page (not the viewport). EG,
rewriting the strict testcase so it works as intended... is it even possible?
> how would I go about writing a document that did position something at the
> bottom of the page

Make the root element position:relative.
Depends on: 243519
Comment 11 is incorrect, since the root element doesn't have a 'height' of
'100%'. What is exactly the bug here?
actually the statement that "absolute" position refers to the viewport is in
correct. According to W3 CSS2.1 specifications, "fixed" positioning refers to
the viewport not "absolute" positioning. "absolute" positioning should refer to
the containing block, and if that block flows outside the viewport should still
be tied to the containing black NOT the viewport.
> and if that block flows outside the viewport

The viewport was mentioned in the context of the containing block being the
INITIAL containing block.  Which is the viewport.  Please try to read a little
more carefully before commenting...
I see the same behaviour with an position:absolute span in a position:relative
td, so there is no "initial viewport" that should be relevant, the containig
block is definitely the containind td. This may be the same thing as bug
#301339
You're seeing bug 63895, so in your testcase the abs pos containing block is
still the initial containing block.  I'd suggest using a <div> instead of a <td>.
Verification that this bug also occurs in IE, but not Opera. (though opera does this weird thing where it expands the page size i.e. you can scroll past the element supposed to be on the bottom if you resize multiple times to the extreme)

Could we see some movement on this?  It would really help for things like footers when using good CSS design techniques.
Opera's rendering is wrong, actually.  See comment 8.  The only reason this bug is no resolved invalid yet is that I want to make sure we retest this to make sure it works right after we fix bug 243519.
Upon close review of the CSS2.1 standard I can see your point.  For others reading, the 'initial containing block' is defined as a rectangle with the dimensions of the viewport starting at the origin of the canvas.  So, if the viewport is smaller than the page, the bottom of the block is always at a distance away from the top of the canvas equal to the height of the viewport.  Elements placed on this border scroll with the page because the origin of the canvas does, moving the border with it.  This seemingly anomalous behavior is not noticed with elements positioned from the top because they are scrolled with the canvas origin and are not affected by the bottom border and thus the size of the viewport.

The behavior people are looking for can be obtained with the following CSS being added to the body:

	position:absolute;
	width:99%;
	margin:1%;

I've set the width to 99% and the margin to 1% to compensate for the normal margin for the body.  When I tried making the width 100%, I got horizontal scroll bars and I wasn't sure what the default margin value was.  It is most likely not a percentage value anyway, so there would be no value to set for width that would compensate exactly for any size of viewport.  I'm not sure why the 1% isn't added to both sides, my CSS reference book (O'Reilly) says that it is applied to the overall margin or each individual side so it might be safer to put 0.5% on both sides if it gives any trouble.

This method works because the absolute positioning is calculated on the body instead of the ICB, the body's height being calculated dynamically from the content.  Thus an element positioned from the bottom border will now be positioned from the bottom of the content.  This isn't exactly the effect I was looking for because when the window is bigger than the content, the footer does not display at the bottom than the window as desired but at the bottom of the content, but I guess I will make do.
This really should be fixed. This bug is still haunting a lot of web designers...
The spec clearly says that the position should be according to the container element, not the viewport: http://www.w3.org/TR/CSS21/visuren.html#propdef-position
Magnus, I think you missed part of the definition of "containing block" somewhere there...  This bug, as filed, is invalid.

Now that we have a way to keep track of tests, marking so.
Status: NEW → RESOLVED
Closed: 17 years ago
Flags: in-testsuite?
Resolution: --- → INVALID
Boris, Yes. I appear to have been incorrect. The spec was confusing on one point.
Apparently, a block only becomes a "containing block" when it have position set to "relative", "absolute" or "fixed", not "static" (default).
http://www.w3.org/TR/CSS21/visudet.html#containing-block-details

I had missed that the spec did exclude the "static" type. I agree: This is invalid. I have created a testcase proving this for people still in doubt or that doesn't know how to do it.
Attached file How to do it
How do I position the third div so that it's at the bottom of the document canvas? Reading the specs just gave me a headache :((
This demonstrates how to place something at the bottom of the canvas instead of the viewport. It works by making body a containing block and then placing children at absolute positions.
Since we modify body somewhat, we might get some strange effects on other positioned elements. I have not studied this at all; just created this small example.
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: