296576 - DIV 100% height expands to 100% but does not limit and scroll within 100%

Status: RESOLVED INVALID

(Core :: Layout, defect)

Description

[Bruno Melloni]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.8) Gecko/20050511 Firefox/1.0.4
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.8) Gecko/20050511 Firefox/1.0.4

It was requested in bug 10212 that this be opened as new bug so that 10212 can
be closed.  Description:

When using a DIV with 100% height the expectation is that the DIV will occupy
exactly 100% of the height of the parent cell.  If there is too little content,
the DIV supplies blank space.  If there is too much content the DIV provides a
scrollbar.

This works in IE (and other browsers), but Mozilla-based browsers only support
half of the expected functionality:  A DIV will expand, but will not stop at
100% and provide a scrollbar.

This functionality is critical for web pages that use "exactly" 100% of the
browser window.  Fox example, our firm uses this feature to show a copyright at
the bottom of the screen.  

Since Mozilla-based browsers just create a high page with browser scrolling
instead exact size with DIV scrolling - the copyright is not always visible, and
our firm has been recommending IE to our customers.  Since Firefox is an
otherwise much better browser, it would be nice to be able to recommend it - if
the bug is fixed.

Reproducible: Always

Steps to Reproduce:
1. Run the attached code in IE.
2. Run the attached code in Mozilla.
3. If you want to see the "proper expansion" in either browser, just comment
some of the rows of <TR><TD>x</TD></TR> entries.

Actual Results:  
Explained in details.

Expected Results:  
Use IE and you will see it.

This bug has been known for years, and been reported many times - but perhaps
not as clearly - so it has been either misunderstood or ignored.  But failing to
correct it gives an edge to your competitors, and can't be that difficult to fix.

Comment 1

[Bruno Melloni]

Attachment: Page that shows the 100% height DIV problem.

After fixing the 100% height problem with the DIV, it might expose a similar
problem with nested tables (or we can hope that it will not), which has
supposedly been fixed through bug 10212.

Comment 2

[Gunnar Nilsson]

Attachment: A simplified testcase

I extrated a simplified testcase from "Page that shows the 100% height DIV
problem."

Comment 3

[Boris Zbarsky [:bzbarsky]]

The height of a div should be independent of the overflow value, so this looks
invalid to me.

Comment 4

[Bruno Melloni]

I am not sure what you mean by "overflow value".

In plain English, it seems logical that when you set an object to 100% height,
it should use 100% of the height available.  IE seems to agree with that
interpretation, since the code works fine there.

But if the developers of the Mozilla browsers do not think so, that is their
prerogative.  We'll continue to recommend to our customers to use IE.  

I know... it is a pretty sad situation, considering that we develop J2EE
applications, not ASP, but we have no choice.  Our applications depend on the
ability of making all pages size to exactly the size of the browser window.

Thanks anyway for taking the time to look into it.

Comment 5

[Boris Zbarsky [:bzbarsky]]

> I am not sure what you mean by "overflow value".

The fact that the div has "overflow: auto" should not affect the height it has.

> In plain English, it seems logical that when you set an object to 100% height,
> it should use 100% of the height available.

This is correct, for quirks mode; the question is what the available height is.
 If the problem is that the available height is calculated wrong in quirks mode
(that is, if removing the overflow style rule still shows a difference in
behavior with IE), please reopen this bug.

Comment 6

[Bruno Melloni]

I apologize if I am misinterpreting what you are saying(In reply to comment #5)
> > I am not sure what you mean by "overflow value".
> 
> The fact that the div has "overflow: auto" should not affect the height it has.

I might be misinterpreting the purpose of the "overflow" property.  But isn't
its purpose to tell the DIV to limit itself to the available space by scrolling,
as an alternative to the default behavior of forcing the space bigger?  (at
least that is what the reference that I am looking at says: 
http://www.w3schools.com/css/pr_pos_overflow.asp)

If not through a DIV overflow, how do you limit maximum size to 100% of the
"space before placing the object" and force a scrollbar?

> 
> > In plain English, it seems logical that when you set an object to 100% height,
> > it should use 100% of the height available.
> 
> This is correct, for quirks mode; the question is what the available height is.
>  If the problem is that the available height is calculated wrong in quirks mode
> (that is, if removing the overflow style rule still shows a difference in
> behavior with IE), please reopen this bug.
> 
> 
I am not sure what quirks mode is.  I thought overflow was part of the CSS
standard and that it is the only way to accomplish the behavior that I am
looking for (please correct me if I am wrong).

If I remove the overflow clause, then both browsers will of course not do the
job of forcing a scrollbar, because there is nothing telling it to have the
scrollbar... which is the whole point of this issue.

If I replace overflow:auto and replace it with overflow:scroll (which is much
more explicit), IE works correctly and Mozilla shows a scrollbar that doesn't
scroll because it is fully expanded in height.

--

Having said all that, I assume it is possible that I am misinterpreting the
standard.  So perhaps rephrasing the issue might help clarify whether this is a
browser issue or an error on my part:

How else (other than the DIV and the overflow property) could this page be done
so that the column of "x"s gets a scrollbar and the Copyright line remains
ALWAYS at the bottom of the browser window, no matter what other content is in
the page or how the browser is resized?

Please note that the DIV might have been inside a large number of nested tables.

So... should I reopen the bug?

Comment 7

[Boris Zbarsky [:bzbarsky]]

> But isn't its purpose to tell the DIV to limit itself to the available space by
> scrolling,

No, its purpose is to say what happens to the content that doesn't fit in the
div. The size of the div is independent of the value of the "overflow" property
and is used to decide _whether_ the content overflows; the "overflow" property
is used to decide with the content that overflowed, if any.

> I am not sure what quirks mode is.

See http://www.mozilla.org/docs/web-developer/quirks/

Per the CSS standard, "height: 100%" as you use it in your testcase is
equivalent to "height: auto" and the div should be as small as it can be
vertically...  In quirks mode we violate the CSS standard for compatibility with
actual websites.

> If I remove the overflow clause

Then we render the same as IE in that case?

> How else (other than the DIV and the overflow property) could this page be
> done

That's really an authoring question, not a spec question....  Per spec I'm not
even sure this _can_ be done.

> So... should I reopen the bug?

This is a valid bug if and only if Mozilla and IE have different layout when the
overflow is set to "visible".  If IE has differences in layout based on the
overflow value, then that's a bug in IE....

Comment 8

[Bruno Melloni]

OK, as far as I can tell from what you are saying is that the standard does not
mandate support for making a DIV exactly 100% (not bigger, not smaller) of the
available space, even if some browsers support it.  So, this may be a flaw with
the CSS standard, but not necessary with Mozilla-based based browsers.

IE supports it in quirks mode because it is a good idea, but Mozilla does not
support it because it is not mandated.

Therefore, the only possible conclusion is that this is not a bug, but for
applications that require the exact 100% behavior (like ours) then Mozilla is
not an option.

Thanks for clarifying this.  The bug does not require reopening.