Open Bug 10212 Opened 25 years ago Updated 1 year 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: