Closed
Bug 216847
Opened 21 years ago
Closed 14 years ago
[quirks]div sized to height: 100%; overflow: auto; refuses to resize
Categories
(Core :: Layout, defect)
Core
Layout
Tracking
()
RESOLVED
FIXED
People
(Reporter: rginda, Unassigned)
References
(Blocks 1 open bug)
Details
(Keywords: regression, testcase)
Attachments
(7 files)
screenshot of how it *should* look
In the upcoming testcase, the div surrounding the "Buddy" text should resize to take up as much space as possible, without pushing the footer off the edge of the window. Instead, the buddy div always takes as much space as it needs.
|
Reporter | |
Comment 1•21 years ago
|
||
Load this testcase and resize your window until it's too small to contain all the "buddy" lines. This should cause a scrollbar between header and footer, which should *always* be visible.
|
|
Reporter | |
Comment 2•21 years ago
|
||
this is what it looked like in mozilla 1.2.1. This regression happened sometime after that, and still exists on a fresh tree from tonight.
|
|
Reporter | |
Comment 3•21 years ago
|
||
This is a big PITA for the DHTML aim client at http://beta.aimexpress.aol.com/ (I've got it running on ns/mozilla internally.) There doesn't seem to be any other way to work around the regression, other than registering an onresize handler and changing the size of the DIV by hand.
|
||
Updated•21 years ago
|
Keywords: regression,
testcase
|
||
Comment 4•21 years ago
|
||
Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.5b) Gecko/20030820 I don´t need to resize, I´m seeing header AND footer only, if I open the testcase in a new window, close all 3 bars ( menu, location, Personal toolbar ) and set my preferences to 'Hide the tab bar when only one tab is open'
According to CSS2 / CSS2.1, our behavior is probably correct, since percentage heights are only supposed to mean something when the parent has a fixed height, and table cells pretty much never have a fixed height no matter what you do. It could be something different for quirks mode, though...
|
||
Comment 7•21 years ago
|
||
I wouldn't be using tables at all in this example - just stick with divs alone. Plus, if you're going to be using overflow and percentages, you really need to set the height of the <body> tag which is the parent (as well as the padding for cross-browser compatibility). If you don't the first div won't have any idea what it should be make 100% of. Old: <body style="margin:0px;"> New: <body style="margin:0px; padding:0px; height:100%">
|
|
Reporter | |
Comment 8•21 years ago
|
||
Well, here's my attempt to do it with divs. I have to set the margin of the body to the size of header + footer, in order to trick the div into thinking height=100% is the size I want. Pretty lame. Now, suppose the header changes it size occasionally, which it does in this app. In order to make this testcase work, I'm going to have to modify the body margin, on the fly, to reflect the new header size. Even lamer. If the size change is caused by text of an unknown height, then it just can't be done reliably. That's about as lame as it gets. Am I missing something here, or is there really no way to do this "by the spec"?
|
|
Reporter | |
Comment 9•21 years ago
|
||
|
|
Reporter | |
Comment 10•21 years ago
|
||
|
|
Reporter | |
Comment 11•21 years ago
|
||
"heights are only supposed to mean something when the parent has a fixed height" Why is that, anyway? The spec seems to go out of its way to pretend that things don't have a height or width unless you set it by hand. It makes it extremely difficult to do resizable windows, decreasing the utility of the spec, and any browser that implements it strictly.
The CSS layout model is designed for documents -- widths go in, and heights come out. There's been discussion of adding an additional layout model to CSS, but this testcase looks like you really want the XUL box model.
|
||
Comment 13•20 years ago
|
||
found the same problem... ...the div size seems to adjust itself to the text with 100% and not to the table it lies in... thats a very annoying problem - pleas solve soon!
|
||
Comment 14•20 years ago
|
||
This behavior (as it is currently implemented) goes against the behavior of other elements. Also, when I set the width of a DIV to 100% and overflow: auto, it scrolls horizontally...why not then virtically? The other major two browsers (IE and Opera) do this "correctly" or "as expected" the div scrolls virtically, as well as horizontally. Going "by the spec" sometimes creates issues that are better fixed by giving the user what they need, not what a spec says they must have...without consideration of "real-world" use cases and need.
Summary: div sized to height: 100%; overflow: auto; refuses to resize → [quirks]div sized to height: 100%; overflow: auto; refuses to resize
|
|
||
Updated•20 years ago
|
Flags: blocking-aviary1.0+
|
||
Comment 15•20 years ago
|
||
Please do not set the blocking-aviary1.0+ flag. the + flags are reserved for use by drivers@mozilla.org or the Aviary team.
Flags: blocking-aviary1.0+
|
|
||
Updated•20 years ago
|
Flags: blocking1.8a4?
Flags: blocking1.7.x?
Flags: blocking-aviary1.0?
|
|
||
Updated•20 years ago
|
Flags: blocking1.8a4?
|
||
Comment 16•20 years ago
|
||
think it is likely that we are going to have to get a patch and some testing on the trunk before talking this on the stable branches. renominate if that happens.
Flags: blocking1.7.x?
Flags: blocking1.7.x-
Flags: blocking-aviary1.0?
Flags: blocking-aviary1.0-
|
||
Comment 17•19 years ago
|
||
I have the same problem today with the version 1.5.0.1. I searched a lot and found the hint of set the height for 0 where you want the height 100%. (Exemple in the next post) Anyone have a good explanation for this behavior of Firefox? I think the IE have a solution for this problem wich is better than the FireFox
|
|
||
Comment 18•19 years ago
|
||
|
||
Comment 19•18 years ago
|
||
the suggested workaround from mateus with height:0 applied to the td where the div resides seems to work on first sight but this "hack" results in a mor quirky behaviour. see my modified attachment (its just the same as mateus but i added a border and width:100% to the table inside the scrolling div). voull notice the useless horizontal scrollbars appear (for the ammount the vert. scrollbars take away). the only way to get rid of the horiz. scrollbars is to apply a fixed height to the div which would defeat the purpose. currently there is no way to achieve the same layout in FF and IE without adding some ugly JS that automatically resizes the div vie athe window onresize header.
|
||
Comment 20•17 years ago
|
||
Hello,
I have partially-resolved this issue, not in a nice way but I did it, by changing this CSS code:
#FullContainer
{
position: absolute;
left: 0;
top: 0;
bottom: 0;
right: 0;
z-index:0;
}
for this:
#FullContainer
{
position: absolute;
width: 100%;
border-right: 0.01em solid red;
z-index:0;
}
Notice that the only change was adding "border-right: 0.01em solid red;" and #FullContainer is a DIV element, is child of BODY and contains all of the other elements.
The first case does not takes the 100% height, but Firefox calculates the height based on its child elements, instead of taking it of implicit value (100%).
In the second case it takes 100% height even if you do not set the "height" property or without setting the top, right, bottom and left attributes.
I hope this will be useful.
Best regards,
Matias
|
||
Updated•15 years ago
|
Assignee: layout → nobody
QA Contact: ian → layout
|
|
||
Comment 21•14 years ago
|
||
noticed this old bug in my votes. checking the attached testcases showed this bug got fixed (maybe quite some time ago). working fine in current 3.6 so closing the bug.
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
You need to log in
before you can comment on or make changes to this bug.
Description
•