26617 - table ignores height and overflow attributes

Status: RESOLVED INVALID

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

Description

[Myk Melez [:myk] [@mykmelez]]

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)

Comment 1

[Myk Melez [:myk] [@mykmelez]]

Attachment: test case with table that exhibits this behavior

Comment 2

[karnaze (gone)]

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.

Comment 3

[Amarendra Hanumanula]

QA contact update

Comment 4

[Christopher Hoess (gone)]

Reopening, futuring.  Tables are CSS2, yes?

Comment 5

[Bernd]

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. 

Comment 6

[Greg K.]

Reconfirmed using FizzillaCFM/2002071208. Setting All/All.

Comment 7

[Laurent Martelli]

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

Comment 8

[Alan W. Presley]

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

Comment 9

[Hoss]

Attachment: testcase showing pixels vs percentage AND nesting

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>).

Comment 10

[karnaze (gone)]

mass reassign to default owner

Comment 11

[Thaddeus Letnes]

Attachment: Another example, using borders and scrolling to illustrate (works just fine in ie)

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)

Comment 12

[Anne (:annevk)]

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

Comment 13

[Alan W. Presley]

unfortunate decision.  

The availability of this in old Netscape and current IE is quite handy for
designers.

Seems that IE wins this round.

Comment 14

[Hoss]

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"

Comment 15

[Anne (:annevk)]

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.

Comment 16

[Hixie (not reading bugmail)]

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