Overview Description: Tables are block-level elements that should respect CSS1/2 height and overflow attributes. However, a long table with 'height: {small height value}' and 'overflow: scroll' or 'overflow: auto' does not obey the height attribute, nor does it create scroll bars. Actual Results: table appears as if height and overflow styles were not there (full height, no scrollbars) Expected Results: table is the height specified in the height attribute and with scrollbars Build Date & Platform Bug Found: Linux 2000-02-04-08 Additional Builds and Platforms Tested On: none Additional Information: if i specify display: block in the style the height and overflow are set correctly but the table also goes to width: 100%. (this is commented out in the test case at the url listed above and also to be attached to this bug because my build is behaving quirky in other ways when it's in there)

If you add a <TBODY> and put the overflow on that, it will do what you want (with some minor glitches). I'm not sure when we will support overflow on <TABLE>s. Marking LATER.

QA contact update

Reopening, futuring. Tables are CSS2, yes?

just a quote from the spec: The height of a table is given by the 'height' property for the 'table' or 'inline-table' element. A value of 'auto' means that the height is the sum of the row heights plus any cell spacing or borders. Any other value specifies the height explicitly; the table may thus be taller or shorter than the height of its rows. CSS2 does not specify rendering when the specified table height differs from the content height, in particular whether content height should override specified height; if it doesn't, how extra space should be distributed among rows that add up to less than the specified table height; or, if the content height exceeds the specified table height, whether the UA should provide a scrolling mechanism. Note. Future versions of CSS may specify this further.

Reconfirmed using FizzillaCFM/2002071208. Setting All/All.

With mozilla 1.0, the following table <table> <tbody style="height:6ex"> <tr><td>cell</td></tr> <tr><td>cell</td></tr> <tr><td>cell</td></tr> </tbody> </table> will not have the requested height. I had to add a <thead><tr><th>head</th></tr></thead>and "overflow:auto" to the tbody's style in order to have the request height

also the specification of height="100%" does not work either, but width="100%" does work. Should be same in both directions but does not display properly. These specs work properly in IE and Netscape. I am using Mozilla build 2002072203 on Mac OS 9 and X Alan

This is a demonstration of some strange table "height" behavior in Mozilla (bug#26617). These are all single tr/td tables that specify the height using the table height attribute (not CSS). The "escaped" HTML code for each table is in body of the table/cell. Note that (at least in Mozilla 1.2.1 on my Linux box) a height specified in pixels works regardless of alignment, or nesting, but a height specified as a percentage does NOT work if the table is nested inside of another tag (ie: <center> or <font>).

mass reassign to default owner

This is based on an app I delivered for a client (only needed to work on IE) tested on Win 2k pro Opera: failed Moz: failed IE 5.5: passed NS 4.7: failed (but usable)

According to CSS2.1 Mozilla is correct. <http://www.w3.org/TR/CSS21/tables.html#height-layout>: > CSS 2.1 does not specify rendering when the specified table height differs > from the content height, in particular whether content height should override > specified height; if it doesn't, how extra space should be distributed among > rows that add up to less than the specified table height; or, if the content > height exceeds the specified table height, whether the UA should provide a > scrolling mechanism. -> INVALID

unfortunate decision. The availability of this in old Netscape and current IE is quite handy for designers. Seems that IE wins this round.

I'll admit, I don't understand all of the relavent specs, nor do I fully understand how decisions are made regarding "legacy behavior" not covered by recent specs, but I'm still confused by this bug. My main interest in it was because the summary said both height *and* overflow attributes were being ignored. I've never even used "overflow" but I've seen several situations in which the "height" attribute didn't work with percentages (comment #8 is what drew me to this bug). Hence my comment #9, and attached sample case. If the CSS spec says specifing a table height different then the content height is undefined... 1) What does that mean for "legacy" percentage values? (should that be tracked in a seperate bug?) 2) That doesn't neccessarily mean "Mozilla is correct", it just means Mozilla can do whatever the developers think is best, there seems to be quite a few people that think adding a scroll bar is what's "best"

Hixie, Why doesn't CSS2.1 uses 'min-height'? Currently 'height' should behave like 'min-height' on tables. Is this done for compatibility with HTML? Since from a CSS point of view, it doesn't make sense. Hoss, your attachment and comments are not related to this bug AFAIK.

from before my time, but yes, CSS table model is vague for compatibility with the legacy table model.