Closed
Bug 234393
Opened 21 years ago
Closed 21 years ago
{inc}absolutely positioned elt. with 'bottom: 0' obscured by horizontal scrollbar
Categories
(Core :: Layout: Positioned, defect)
Tracking
()
RESOLVED
DUPLICATE
of bug 211562
People
(Reporter: justinarthur, Unassigned)
Details
(Keywords: css2, testcase)
Attachments
(1 file)
(deleted),
text/html
|
Details |
User-Agent:
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040113
The bottom panel of the referenced web site is styled in CSS. It is positioned
via the following CSS properties:
bottom: 0px;
left: 0px;
right: 0px;
position: absolute;
margin: 0px 0px 0px 0px;
This worked fine in Internet Explorer 6 and Mozilla 1.5; however behaves rather
interestingly in Mozilla 1.6, oftentimes positioning the panel below where it
ought to be (very bottom of page).
Reproducible: Always
Steps to Reproduce:
1. Visit the web site.
Summary: Absolute positiniong behavior appears erratic. → Absolute positioning behavior appears erratic.
Comment 1•21 years ago
|
||
Regarding the .css file
http://justinarthur.deepstructure.info/index.css
------------------------------------------------
Setting left and right offset values to an abs. pos. element can not be honored
simultanously for sure.
.footpane {
width: 100%;
bottom: 0px;
left: 0px;
right: 0px;
position: absolute;
/* If the goal is to position the div at the bottom of the viewport, then
position:fixed is the way to go; see bug 105286 */
Declaring
width: 100%;
height: 31px;
border: 2px solid Gray;
will create an overflow since such width value does not take into consideration
the padding, border and margin value. So, the element uses 100% of the available
width as given by its immediate parent (which is the Initial C.B.) and adds
borders around it. Such overflow will bring an horiz. scrollbar.
font-size: xx-small; /* xx-small is very small font-size value and can be
overriden by user settings in Edit/Preferences.../Appearance/Fonts/Minimum font
size. Now, if overridden, then the text will wrap and the height of the cell
will be greater than 31px, again bringing another issue */
I examined carefully the .css file
http://justinarthur.deepstructure.info/index.css
and I am convinced that at least 9 css declarations are pointless or irrelevant
(and should have been removed) while 3 are contradictory or wrong or causing issues.
One point I was not able to understand is what this declaration (found in html.css)
table {-moz-box-sizing: border-box;}
does exactly.
The .css file
http://justinarthur.deepstructure.info/index.css
is over 80 lines and can not serve to enlighten, to corner precisely a bug. A
reduced testcase would be necessary here.
In any case, I don't understand how or why one should link this bug to bug
232838: there is no explanation, no demonstration, no reasoning given to that
effect. Scrollbar or scroll is not even mentioned anywhere in the summary or
description or actual results of this bugfile.
FWIW, I set/changed position to fixed and removed the 2px gray borders around
the footpane table and everything behave accordingly: the footpane div
positioned itself at the bottom of the viewport.
Mozilla 1.7alpha build 2004021508 under XP Pro SP1 here.
Reporter | ||
Comment 2•21 years ago
|
||
Points taken. It is quite possible that a bug in Mozilla 1.5 and IE6 actually
allows this to render as the author had intended.
Comment 3•21 years ago
|
||
No, there's a real bug here, and it has something to do with not repositioning
elements relative to the bottom when the scrollbars are added.
Status: RESOLVED → UNCONFIRMED
Resolution: INVALID → ---
Updated•21 years ago
|
Assignee: dbaron → nobody
Component: Style System (CSS) → Layout: R & A Pos
Depends on: 211562
QA Contact: ian → core.layout.r-and-a-pos
Summary: Absolute positioning behavior appears erratic. → {inc}absolutely positioned elt. with 'bottom: 0' obscured by horizontal scrollbar
Comment 4•21 years ago
|
||
Note that comment 1 does explain why there's horizontal overflow (although it's
worth noting that specifying both 'right' and 'left' can make sense when 'width'
is 'auto' (unspecified)). However, it doesn't explain why we sometimes position
the absolutely positioned element above the scrollbar and sometimes under it.
Comment 5•21 years ago
|
||
(In reply to comment #4)
> (...) However, it doesn't explain why we sometimes position
> the absolutely positioned element above the scrollbar and sometimes under it.
In comment #1, I should have been saying
(...) uses 100% of the available width as given by its **offsetParent** or
**nearest containing positioned element** (which is the Initial C.B.)(...)
instead of **immediate parent**
I wish you could direct me to some document explaining what do/are these
declarations:
*|*::-moz-viewport-scroll {
overflow: auto;
}
and
table {-moz-box-sizing: border-box;}
As far as I can say right now, this bugfile seems like a DUPLICATE of bug 211562.
Comment 6•21 years ago
|
||
In this bug, zooming makes the problem go away, but in bug 211562 it does not.
Please don't confuse bugs with unrelated issues.
Reporter | ||
Comment 7•21 years ago
|
||
Reporter | ||
Comment 8•21 years ago
|
||
I hope the HTML I just attached serves as a cleaner test case. Sorry about
putting you through the mess of my personal web site in progress before. :)
Waiting for confirmation, and affected operating system clarification.
Keywords: css2
Isn't bug 234393 actually a duplicate of bug 211562?
The last line in the testcase is really obscured. There is no vertical
scrollbar. But you can scroll the page using the arrow keys. That is interesting.
I can confirm this with Firebird 20040128. It was working in Moz 1.5.
Comment 10•21 years ago
|
||
Win 98/2k.
Reporter | ||
Comment 11•21 years ago
|
||
Changes to bug 211562 descriptions have rendered this bug a dupe of it.
Reporter | ||
Comment 12•21 years ago
|
||
*** This bug has been marked as a duplicate of 211562 ***
Status: UNCONFIRMED → RESOLVED
Closed: 21 years ago → 21 years ago
Resolution: --- → DUPLICATE
You need to log in
before you can comment on or make changes to this bug.
Description
•