Hi! Go to "http://www.fh-muenchen.de/home/ze/rz/services/projects/xcdroast/xcdr098/" and on the left side there are some Buttons ("News", "Overview", ...). Between these buttons there is some space which shouldn´t be there (=> she NS 4.7, IE, ...). => I think we have to blame the Table in which these buttons are?!

Confirming (kind-of) but this could be ascribed to pilot error. Basically the pattern is : <table width="100%" height="100%"> <tr><td> <table height="100%"> <tr><td height="1"> xxx </td></tr> <tr><td height="1"> xxx </td></tr> </table> </td><td width="100%" height="100%"> blah blah blah </td> </tr></table> ... so what should take priority: the request for the inner table to have height=100% or the request to limit the heigth of the TD of the inner table to be height=1. Arguable either way I suppose (unless there is some definitive statement in HTML4, but I don't think so). In the end, the author obviously doesn't want <table height=100%> for the inner table, and the fix is trivial for the author to make. (You could mark this as WONTFIX based on the contradictory constraints that the author has chosen).

spamming myself (and y'all)

...

If I interpret the spec correctly the height of the inner table should be 100%. See http://www.w3.org/TR/REC-CSS2/tables.html#height-layout IE5 and Mozilla (2000-03-27-18 on NT4) is correct. NS 4.72 is not.

Yeah, I would read that, on balance, as 'explicit table height overrides explicit row height', but note that the spec then says what to do is undefined. Overall, I think the mozilla implementation (and ie5) is the right path. However, I just noticed one tiny flaw in the layout of the attachment. Basically, it looks like there is a small error in accounting for the margin/cellspacing of the inner table -- the result is that the vertical scrollbar is displayed. This should not happen when the only content on a page is a nested table with 'height=100%' (by definition). I'll attach another version of the previous attachment, that exaggerates a few things, and makes the flaw a little clearer.

Moving to M18. The url looks ok now.

This bug has been marked "future" because we have determined that it is not critical for netscape 6.0. If you feel this is an error, or if it blocks your work in some way -- please attach your concern to the bug for reconsideration.

Adding testcase keyword so this doesn't show up on the bugathon search page.

QA contact update

Is this a dup of bug 32205 ?

WFM win98 2001-12-29

I still see problems when resizing the window vertically. For example, the inner (blue) table in attachment 7069 [details] is not resized properly. I also get different results depending on how fast I resize the window. (2002-01-01-03/trunk on Win98)

wfm with 20020805 on win2k

attachment 46275 [details] is still significantly different between mozilla and IE5.5 (6?). Haven't really pondered which is 'correct' (involves height of 200%). Anyways, still future.

I believe this is WFM win98 2002100416. I dont see what Mats is seeing. I believe this is zoombie bug. I prefer the mozilla over the IE rendering of attachment 46275 [details].

The resizing problem with attachment 7069 [details] observed in comment 15 now worksforme, 2002-11-30-05 Linux. The original URL is 404. I think the page has moved to http://www.xcdroast.de/ which also WFM.

wfm win98 2003011208