Closed Bug 196937 Opened 22 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)

Product:
Core
Component:
Layout: Positioned
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED INVALID

People

(Reporter: ajp+mozilla, Unassigned)

References

Details

(Keywords: testcase)

Attachments

(6 files)

testcase #1
322 bytes, text/html
Details
strict testcase
870 bytes, application/xhtml+xml
Details
Testcase with span in a td
1.46 KB, text/html
Details
How to do it
1023 bytes, text/html
Details
How to do it on page with scroll ?
1.70 KB, text/html
Details
How to place at bottom of canvas instead of viewport
3.19 KB, text/html
Details
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: