Open Bug 10212 Opened 25 years ago Updated 7 months ago

Height: 100% does not work when nesting tables

Categories

(Core :: Layout: Tables, defect, P3)

defect

Tracking

()

Future

People

(Reporter: monfera, Unassigned)

References

Details

(Keywords: compat, testcase, Whiteboard: please read comment 27 before commenting)

Attachments

(7 files)

Height: 100% does not work when nesting tables (Width: 100% works OK), meaning
that the inner table is not utilizing the full height of the cell of the parent
table it is located in.

This problem has always been there (I looked it from builds M5 to M8).

I met this problem as my application depends on it. I was using the W3 site as
CSS reference.  The example below shows that 100% works for Width and does not
for Height:           (It works OK on IE5)
<HTML>

<HEAD><STYLE>
TABLE {height: 100%; width: 100%}
TD { border: 1px inset steelblue}
</STYLE></HEAD>

<BODY><TABLE style='height: auto; width: auto'>
  <TBODY>
  <TR>
    <TD>Cell 1,1</TD>
    <TD>
      <TABLE>
        <TBODY>
        <TR>
          <TD>Cell 1,1</TD>
          <TD>Cell 1,2</TD>
          <TD>Cell 1,3</TD></TR>
        <TR>
          <TD>Cell 2,1</TD>
          <TD>Cell 2,2</TD>
          <TD>Cell 2,3</TD></TR>
        <TR>
          <TD>Cell 3,1</TD>
          <TD>Cell 3,2</TD>
          <TD>Cell 3,3</TD></TR></TBODY></TABLE></TD>
    <TD>
      <TABLE>
        <TBODY>
        <TR>
          <TD>Cell 1,1</TD>
          <TD>Cell 1,2</TD>
          <TD>Cell 1,3</TD></TR>
        <TR>
          <TD>Cell 3,1</TD>
          <TD>Cell 3,2</TD>
          <TD>Cell 3,3</TD></TR></TBODY></TABLE></TD></TR>
  <TR>
    <TD>Cell 2,1</TD>
    <TD>Cell 2,2</TD>
    <TD>
      <TABLE>
        <TBODY>
        <TR>
          <TD>Cell 1,1</TD>
          <TD>Cell 1,2</TD></TR>
        <TR>
          <TD>Cell 2,1</TD>
          <TD>Cell 2,2</TD></TR>
        <TR>
          <TD>Cell 3,1</TD>
          <TD>Cell 3,2</TD></TR></TBODY></TABLE>
    </TD></TR>
  <TR>
    <TD>Cell 3,1</TD>
    <TD>Cell 3,2</TD>
    <TD>Cell 3,3</TD></TR></TBODY></TABLE></DIV></BODY></HTML>
Assignee: don → karnaze
Component: Browser-General → HTMLTables
Moving this bug to HTMLTables and karnaze.

cc'ing troy since he knows a lot about percentage heights.  I'm not sure if
this *should* work.  It probably should work in some cases, but which?
Certainly when the height of the cell is given.  What about the row?  (I think
not, because row heights are really min-heights.)  In which is it working now?
Whiteboard: [TESTCASE] klein_sh@inter.net.il
Status: NEW → RESOLVED
Closed: 25 years ago
Resolution: --- → REMIND
We support percentage heights on non nested tables inside the body using the
viewport as the percentage base. This is done for compatibility reasons (not
because it has support in the CSS 2 spec). Since Nav4.6 doesn't support
percentage heights on nested tables, I'm marking this "remind".
QA Contact: leger → chrisd
Updating QA contact.
Status: RESOLVED → VERIFIED
Verified Remind.
REMIND is deprecated.
Status: VERIFIED → REOPENED
Keywords: compat
Resolution: REMIND → ---
Since "height" is only supported for compat purposes anyway, I'm marking this
WONTFIX. Reopen if the will of layout is otherwise.
Status: REOPENED → RESOLVED
Closed: 25 years ago22 years ago
Resolution: --- → WONTFIX
When I filed the bug report, I did not have compatibility in mind.  I had a 
requirement, which is nesting a table inside another table such that the 
contained table expands (if necessary) to fill the containing cell.  Otherwise 
these nested tables look pretty ridiculous.  There is no other way I am aware 
of to achieve what I need other than using IE.  The entire concept of 
specifying heights and widths in percentages is a system-wide concept, and 
tables should not be excluded just because some Netscape version written long 
ago didn't support it.  I think what I want is supported or required by the CSS 
standard.  Please give my example a try in Gecko as well as Internet Explorer 
and make sure you have an understanding and appreciation for percentage-based 
dimension determination.
Status: RESOLVED → REOPENED
Resolution: WONTFIX → ---
I spent a lot of effort supporting percent height thingys inside cells which 
have no computed heights in all modes (quirks, almost standards, standards). 
Without this capability, there are a lot of pages that won't look right, and 
even if the authors changed those pages, some would not be able to achieve 
what they want. 

The test case in this bug looks a lot better than it did when the bug was 
opened, but one of the tables is still not streching to fill the height.
Status: REOPENED → ASSIGNED
Target Milestone: --- → mozilla1.1beta
QA Contact: chrisd → amar
This problem is evident on the following topsite:
http://www.zelius.com/default2.asp
The image "bandeau_gauche.gif" is getting clipped at the bottom due to the
height issue in nested tables.
It appears the table in row 1, column 3 still exhibits the problem.
Interestingly, when you also apply height:100% to the TBODY elements, that table
does stretch vertically to fill its' parent cell.
Blocks: 171491
Attached file example in div
I see simliar problems with height=100% when a single table is inside of a
<div> ... </div> block.

I created an attachment to show this. In IE 5.5 on W2K the table fills the
entire browser window, which is how I think Mozilla should handle it. When the
<div> & </div> tags are removed, both render the table to fill the entire
browser window.

The milestone should probably be updated (I am using 1.1).
<table height="100"> also doesn't work inside a <span> </span>
Not just DIV or SPAN nesting ---the height-percentage attrib is broken when
preceded by *any* (apparently) tag that affects vertical layout, except for BR.

In the following sample URLs, the only difference is that a single <P> proceeds
the tables in one and not the other.

http://www.kensystem.com/calendar.jsp.html
http://www.kensystem.com/calendar2.jsp.html

The devatstating stylistic handicap of not being able to set relative-heights
becomes _violently_ apparent on the calendar that is trying to be represented by
these samples. (Did I emphasize that enough?? :->)
mass reassign to default owner
Assignee: karnaze → table
Status: ASSIGNED → NEW
QA Contact: amar → madhur
Target Milestone: mozilla1.1beta → ---
Target Milestone: --- → Future
Whiteboard: [TESTCASE] klein_sh@inter.net.il → klein_sh@inter.net.il
Keywords: testcase
Hmm, I wonder if bug 195732 is a dupe of this bug.
I wonder if this bug is a quirks bug.

as shown in
http://www.w3.org/TR/2003/WD-CSS21-20030128/visudet.html#the-height-property
<percentage>
Specifies a percentage height. The percentage is calculated with respect to the
height of the generated box's containing block. If the height of the containing
block is not specified explicitly (i.e., it depends on content height), and this
element is not positioned, the value is interpreted like 'auto'.

for example

<div>
 <table style="height:100%">
  <tr><td>foo</td></tr>
 <table>
</div>
The height for the table must be auto. If there is another major browser, which
is known for its block problems, now defines that the 100% refer to the viewport
than it violates the CSS2 spec. So the question here is would we like to
implement a IE quirk.

The place to do this would IMHO be: at nsHTMLReflowState.cpp
1791       if (NS_AUTOHEIGHT == aContainingBlockHeight) {
1792         // this if clause enables %-height on replaced inline frames,
1793         // such as images.  See bug 54119.  The else clause "heightUnit =
eStyleUnit_Auto;"
1794         // used to be called exclusively.
1795         if (NS_FRAME_REPLACED(NS_CSS_FRAME_TYPE_INLINE) == mFrameType) {
1796           // Get the containing block reflow state
1797           const nsHTMLReflowState* cbrs = parentReflowState->mCBReflowState;
1798           NS_ASSERTION(nsnull != cbrs, "no containing block");
1799           nsCompatibility mode;
1800           aPresContext->GetCompatibilityMode(&mode);
1801           // in quirks mode, get the cb height using the special quirk method
1802           if (eCompatibility_NavQuirks == mode) {
1803             if (!IS_TABLE_CELL(fType)) {
1804               aContainingBlockHeight =
CalcQuirkContainingBlockHeight(*cbrs, PR_FALSE);
1805             }
1806             else {
1807               heightUnit = eStyleUnit_Auto;

I have no intention to work on a quirk, this might be necessary for the nscp/aol
if yes they find the resources I will review a patch if it has passed the
regression tests (they are mandatory as the quirks behaviour changes)
test case consists of outside table with fixed height rows and some sub-tables
spanning multiple of those rows. Only the top sub-table in each column seems to
get expanded vertically correctly.
Using a percentage value NEVER works for "height" in any instance for me, yet a
percentage value for "width" always works.  Trying to design a web page with an
image or text that you wish to keep dead center of the browser by putting it
inside of a table with attributes of <table width="100%" height="100%"> will end
up justifying it to the top of the browser window.  It simply does not work and
has not worked since M5.  It worked fine before, and currently in IE and Safari.
 This problem isn't just with Windows 95, I've seen it on XP and on the Mac.
OS: Windows 95 → All
Hardware: PC → All
*** Bug 195606 has been marked as a duplicate of this bug. ***
This example illustrates the problem (I suppose) in another way. Here I am
trying to make a table fit the window 100% (height) and then put a DIV tag with
overflow-scrollbars inside that table.

The expected output is a table that fits the window with scrollbars *inside*
it, making it possible to view the inner data without scrolling the whole
window.

Works on IE 6.0.

I'm not 100% sure whether my rendering expectations are correct, but they do
seem likely.
requested in 1999. Can it be fixed for 2003?
Flags: blocking1.6b?
Flags: blocking1.6b? → blocking1.6b-
Frankly, I'm not sure we _can_ fix this easily... Doing the 100% height thing
across table cells is bound to break some sites (because IE doesn't do it in all
cases) and will probably break a lot more sites than it fixes....
As a matter of fact, what exactly is IE's behavior on the first testcase in this
bug?  What if you remove the doctype?

Note that the other testcases are about different issues as far as I can tell;
the only relevant one is the first testcase.
(In reply to comment #24)
> As a matter of fact, what exactly is IE's behavior on the first testcase in this
> bug?  What if you remove the doctype?
 
That testcase looks identical in IE6 as Mozilla. Removing the doctype results in
that the upper table to the right gets a height of 100%.
*** Bug 166630 has been marked as a duplicate of this bug. ***
OK.  So IE's being all quirky on us here. Can someone please investigate
_exactly_ what IE's behavior is in quirks mode?  Please make sure to also test
documents which have enough text to overflow the viewport.
After reading the bug comments I can see that only simple-page tests have been
made on this issue.  

I have used the 100% height feature extensively with multiply nested tables and
I can confirm that when properly understood and used it always works in IE for
both expanding up to the size, and contracting a DIV to the 100% of available
space.  In Firefox, Mozilla and Netscape it works for expanding but not for
size-limiting a DIV.

In addition to the failure to size-limit, the Mozilla-derived browsers also seem
to have problem handling DIV widths, as they almost always will provide too
small of a space for the content and forces the user to do horizontal scrolling
even when there is plenty of horizontal space outside the DIV to expand to.

I don't know if using the height=100% is part of the standard or just "common
knowledge" as the ONLY way to make the content to always fit in the viewable
browser window -- very important if you want to ensure that, for example, the
copyright notice at the bottom of the page is always displayed.

So, regardless of whether this is a bug or not I would strongly recommend making
this work.

I would be glad to provide a sample of a fairly complex piece of code that
misbehaves in Mozilla and works in IE.  But because of confidentiality issues I
cannot post it publicly here.  If the developer that is going to fix this issue
wants such code, please contact me via email.

Bruno
I forgot to mention... the funky size recognition of 100% DIVs is very bad in
Mozilla/Firefox/Netscape.  It resizes to a different size every time you refresh
or redisplay... it is not even consistent about how wrong it is.  And it is a
problem in both width and height.
This is an example of a reasonably complex (and thus realistic) page that uses
table nesting and 100% height.	This page works flawlessly in IE but fails to
height-limit in the Mozilla-based browsers.  

Without the bug fix it is probably impossible to make this page work correctly
in Mozilla, and even less likely to find a way to make it work on both IE and
Mozilla.

I have even more complex pages that I can provide as examples, if desired.
What is the conceptual problem here?!? A table with attribute height=100%
inside a defined box (cell in another table for instance..) should take up all
the vertical space. Seems pretty obvious to me. Why are the top two sub-tables
in this simple example doing this and not the others? Seems like a bug to me.
Who's quirky now?
Indeed... the concept is trivial.  And the problem is not only with height, it
is also with width.  The height fails to limit, but the width in a DIV becomes
random even if you use a fixed max-height.  When the same page displays
differently at each refresh you certainly get to notice, especially when the
other browsers work fine.

Since our apps are impossible without 100% heights and widths, when customers
complain about it we are forced to tell them to use a better browser.  

Since I prefer Mozilla myself, this feels very, very wrong.

Please, please, please... fix this mess.
Dear fellows,

this bug does not get any better by adding rants, the only thing that is
required is to answer the questions in comment 27. Precisely, so that it can be
implemented. Bug 269156 is a good example of how this can be done. I hope people
sooo concerned, will spend theire time on a precise description.

Bernd
Whiteboard: klein_sh@inter.net.il → please read comment 27 before commenting
I disagree wholey with comment 27 - IE is not being quirky - its doing what
every other browser in the word does - its the 'spec' that's quirky because it
completely ommitted what a table's height attribute behavior should be when
expressed in percent, last time I check some 3 or 4 years ago. This
'spec-quirky-ness' has been the premise for all these years of Mozilla not doing
what the other browsers do. 

If a height-percent declared table or td would simply expand to the vertical
space of its parent, everyone would be happy - vs. adhering to a spec that few
if any web designers would ever agree with, and that only HURTS this browser.
> What is the conceptual problem here?!? A table with attribute height=100%
> inside a defined box (cell in another table for instance..) should take up all
> the vertical space.

The question is what "all the vertical space" is.  Sometimes that's the
viewport, sometimes not.  IE's behavior seems to be inconsitent.  See comment 25.

Again, what's needed is a clear description of when IE treats "all the vertical
space" as the viewport, and when it treats it as something different.

Ken, the quirkiness of IE is not in relation to any spec but simply because it
uses a variable definition of "all the vertical space".   Your comment is wholly
unrelated to this bug, as are all the other comments after comment 27....
OK, here's my application that got me in this 'feature's way:
http://marius:geheim@gpshack.dyndns.org:8080/
It's a demo of voter verifiable receipts (chaum stuff). I needed to render
ballots and print top and bottom layers (think visual crypto). Obviously
everything needs to line up etc so i print using white for stuff the layout
engine needs to think about but not show. All ugly and hacky but the only way i
could think of getting it done in plain HTML.
In IE everything works as expected, tables stay same size, color cues work on
the touchscreen etc. With gecko, table sizes jump around, the height doesn't
stick, a mess.
At least with my nested tables, IE behavior seems very consistent. I can't think
of a reason why gecko can't behave the same here.
Any suggestions as to how to make this application work with gecko are more than
welcome. I tried poking at the firefox source but no luck so far, seems tricky.
Obviously we wouldn't want to vote using IE..

marius
I apologize if anyone thought I was ranting when asking for this issue to be
fixed.  But since the issue was being ignored (bug opened in 1999), it seemed
that what was needed was a reason to implement it, which is what my last comment
said.  

As to comment 27... I have no idea what it is about, I have experienced zero
quirks in regard to this issue from IE, only behavior that I expected.

The issue is simple, at least in my case:  "If a tag is inside another one, and
is given 100% height or width, it should get 100% of the available space in the
parent tag, after squashing all padding space in their sister tags.  The display
should be adjusted to preserve the 100% rule when the browser window is resized."  

This is exactly what IE and other browsers seem to do.

Note that if you want to have a <TD> or <DIV> use all available space in a page,
you have to RELIGIOUSLY grant its parent chain 100%, all the way up until you
hit the <BODY> tag or a tag with a fixed size that determines a new "100%".

I already provided a real-life medium complexity page that shows this problem. 
Marius provided another.  I can provide some that are even more complex.  

You can easily create your own problem pages by nesting 3 or 4 tables, giving
100% to one of the <TD>s in the innermost table and all of its parent tables and
<TD>s.  The plop a <DIV> inside that <TD>, with 100% width and height, and put a
table inside that <DIV>.  

What you will see in most browsers is that you can hit "refresh" or resize the
browser window, and everything will adjust while keeping the whole page inside
the viewable space and preserving the proportions (as long as there is empty
space).  The total height of the page will be EXACTLY 100% of the screen, and
the DIV will use all available space while bringing up the scrollbar if it has
too many rows.

What you will see in Mozilla is that (a) if there are too many rows in the DIV,
the scrollbar does not come up and the page extends past the viewable space (b)
if there are too few rows the total page height will be correct but the div will
randomly be either the height of the parent TD or any height in between (c) the
DIV will almost always have a horizontal scrollbar even when the content is not
wide enough to justify it and part of the contant will be obscured on the right
(d) when attempting to resize anything may happen... but certainly not a proper
resize.

From all the information in this thread of comments I fail to see what is not
clear about the problem.  It is 100% reproducible and there are several examples
provided.  Testing can be done by running those examples on IE and other
browsers and comparing the results with Mozilla.  I (and probably others) am
willing to provide more examples of code that fail to work on Mozilla, but it is
hard to know what else to provide.

Bernd, can you please clarify exactly what it is that you don't understand about
the problem?
I have tested all the attached and linked testcases, and I don't se any problem 
anymore, with:
  "Mozilla/5.0 (Windows; U; Windows NT 5.1; sv-SE; rv:1.7.8) Gecko/20050511
Firefox/1.0.4"

So I think this should be closed!

However there are a similar problem with iframe, and height="xxx%", 
see bug 295717 and bug 253363

(In reply to comment #38)
> I have tested all the attached and linked testcases, and I don't se any problem 
> anymore, with:
>   "Mozilla/5.0 (Windows; U; Windows NT 5.1; sv-SE; rv:1.7.8) Gecko/20050511
> Firefox/1.0.4"
> 
> So I think this should be closed!
> 
> However there are a similar problem with iframe, and height="xxx%", 
> see bug 295717 and bug 253363
> 
> 

I have tested with Firefox 1.0.4 and I agree to a point... it seems to be much
better than it used to be. But I am still having a problem with a DIV not being
limited in height to 100% but rather going to full height - I will review the
code in question one more time today, to make sure the error is not mine, and
either post a sample page showing the problem, or confirming that the issue is gone.
(In reply to comment #38)
> I have tested all the attached and linked testcases, and I don't se any problem 
> anymore, with:
>   "Mozilla/5.0 (Windows; U; Windows NT 5.1; sv-SE; rv:1.7.8) Gecko/20050511
> Firefox/1.0.4"

What about for instance https://bugzilla.mozilla.org/attachment.cgi?id=123668
Shouldn't all encapsulated tables expand to their encapsulating cell heights,
not just the 1st tables for each column of the encapsulating table?
(In reply to comment #39)
Ok I looked again and I was wrong on at least 2 testcases:

1)
"Reasonably complex page example   	multipart/zip"

This testcase has not any DIV, but instead has IFRAME (which is covered by bug
295717 and bug 253363)

So I still think this bug 10212 should be closed.
You should enter an new bug, if you still can produce a test-case for your DIV
problem.

2)
"another nested table height failure testcase, show correctly in IE   	text/html"
 https://bugzilla.mozilla.org/attachment.cgi?id=123668
I looked again and I agree it fails (,maybe the testcase are not that obvious)
I also tested it with:
  IE/6.0 ....... OK
  Avant/10.0 ... OK
  Opera/8.0 .... Also Fails, but more consistent.

So to bring some order to this mess, I suggest that each testcase, that still
fails, should be reopened as separate bugs.

 
This attachment (div.html) is a stripped out version of one of our real pages. 
It shows how the DIV expands to 100% (if you comment some of the rows) but
fails to stop the height at 100% of the vertical space (you get a huge vertical
page that you have to scroll, instead of scrolling the DIV itself).

This functionality works perfectly in IE, but looks very bad in the
mozilla-based browsers.  

Using max-height in the DIV style breaks the functionality in IE (which is 90%
of our customer base) without fixing the problem for mozilla-based browsers.

As you can guess by the copyright at the bottom of the page, this feature is
critical to commercial software.  Mozilla's failure to show it has made our
company recommend IE - quite sad, since Firefox is such a superior browser
otherwise.
(In reply to comment #41)
> (In reply to comment #39)
> So to bring some order to this mess, I suggest that each testcase, that still
> fails, should be reopened as separate bugs.
> 
>  

As requested, I created a new bug, #296576, and included the same information
and attachment as supplied with my last comment.  

But since the 100% height for nested tables cannot be totally tested without
fixing the DIV issue first, I suggest that this bug remain open until the DIV
one is solved so that the interaction between the two can be fully tested. 

Having said that and if everything goes well, I suspect that no other changes
may be needed to the 100% table code.
I wonder if this bug will ever be fixed.  It's been around since 2002.  And the
bug that was recently created as requested in this thead was never handled
either.  Any insight as to why it might be getting ignored would be welome.

I suppose we will have to continue recommending to our customers that they use
IE.  Because of this bug our product does not look good enough on Mozilla.
I have the same problem with nested tables with 100% height.

Most of the time it displays the same page correctly but sometimes it shrink the page vertical and center it to the middle of the screen. Clicking the refresh button result in showing the page correctly again.

In I.E. 5/6/7 it always show the page correctly.

Im working with version 2.0.0.1
Assignee: layout.tables → nobody
QA Contact: madhur → layout.tables
Re-verified using latest example on Aurora 8.0a2.  Copyright sticks to the bottom of the window in IE, off the bottom in Firefox.
Severity: normal → S3

The severity field for this bug is relatively low, S3. However, the bug has 15 votes.
:dholbert, could you consider increasing the bug severity?

For more information, please visit auto_nag documentation.

Flags: needinfo?(dholbert)

The last needinfo from me was triggered in error by recent activity on the bug. I'm clearing the needinfo since this is a very old bug and I don't know if it's still relevant.

Flags: needinfo?(dholbert)
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: