139201 - TD height attribute ignored in TBODY with style of scroll:auto

Status: RESOLVED INVALID

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

Description

[Rick DeBay]

This is a regression from 0.9.9.  I'm using 2002041711 RC1.

To scroll a table body, the style is set to scroll:auto and height:350px.
The cell height is set to 1% to prevent the cells from stretching to fill the
entire tbody if there are only a few rows.  In every version before RC1, this
worked fine.  Now the height is being ignored and the rows are being stretched
vertically.

Comment 1

[Rick DeBay]

Attachment: <TABLE> demonstration

Comment 2

[Rick DeBay]

I misspoke in the initial problem description.  The style of the tbody is:

TBODY.tbodyScroll {overflow:auto}

Comment 3

[Kai Lahmann (is there, where MNG is)]

Rick: could you add a compleate HTML file? As far a there's no style, it's
displayed right

Comment 4

[Rick DeBay]

Attachment: Complete page

Here's the full page from our server.

Comment 5

[Rick DeBay]

I added a URL.  Use the Guest Login page.  This site is still under development,
so it may be down from time to time.

Comment 6

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Chris, this sounds like it could be related to your cell-height work.

Comment 7

[Rick DeBay]

Adding regression keyword that I forgot when creating the bug.

Comment 8

[Rick DeBay]

There is no known workaround.  I removed the height="1%" attribute, and
added style="max-height:1em" to the TR and style="height:1em" to the TD,
and every combination possible using CSS height attributes.

Comment 9

[Rick DeBay]

The first time I view the table, the row height is correct.  From then on,
the row heights are incorrect for any similarly constructed table.
If the browser is restarted, the row height is correct for the first viewing
and incorrect if viewed again.

Comment 10

[Amarendra Hanumanula]

 Confirming the bug. I see the problem on branch builds: 20020613 on WIN2K

Comment 11

[Rick DeBay]

This bug should make 1.1, as it is a regression that breaks HTML 4.0 support
that existed in 0.9.9.
This is one of the really cool table features that HTML 4.0 specifies, yet no
one supports it (well, Mozilla did for a few releases).

Comment 12

[karnaze (gone)]

I'm not sure the previous behavior was necessarily correct. The tbody will
scroll if enough rows get added, but I guess the objection is that the row
heights will change as more rows are added. 

When a tbody (whether scrolled or not) has a height, it doesn't leave any of its
space empty. It tries to honor style heights on the rows unless all of them have
style heights, in which case it allocates the extra to all of them
(proportionally to their style heights). 

I think the simplest way to work around this is to add an extra row (with an
empty cell in it) at the end of the tbody. Since it will have auto height, all
of the extra height will be given to it. It's not quite the same, but close.

I'm marking this as wontfix. If the workaround is not sufficient, please reopen.

Comment 13

[Rick DeBay]

No, this isn't a valid fix.  Listing a workaround doesn't count (BTW, the work
around doesn't).  Please READ the bug report.  The problem is not that the row
height changes as more rows are added, it's that the row height is not honored
after the 0.9.9 release.
I specified a height for each of the rows.  I specified it using attributes,
styles, percentages, and pixels.  None of them worked.  Correction, they worked
the first time the table was viewed.  After that it failed.

Comment 14

[Rick DeBay]

I think clarification is needed here.  I ran in to this problem before, and had
the bug closed as I needed to define the row height.  This worked through
version 0.9.9, and now Mozilla "tries to honor style heights on the rows unless
all of them have style heights, in which case it allocates the extra to all of
them (proportionally to their style heights)."
Which is another hoop web developers have to jump through.  I can understand the
first argument "you didn't define a height, so all your row heights were
stretched."  Now I am defining a height, and it's being ignored.  There is no
way I want to add an extra row 'just in case.'  And I can't imagine the
spagehtti my JSP will become if I have to total the heights of all my rows to
see if I have to add the extra line.
I examined http://www.w3.org/TR/1998/REC-CSS2-19980512/tables.html (at this late
hour...) and couldn't find anything that clears this up.  17.5.1 says that the
rows fill the table from top to bottom, but 17.5.3 specifies that rows should be
their given height.  HOWEVER "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."
Given that the new behavior was sprung on developers out of the blue (yeah boss,
it works great with 0.9.9, can't see why it won't work with 1.0, see I told you
there was a good reason not to support IE only...) and that it pretty much makes
the use of scrolling tables (a very useful feature) onerous, I suggest that the
0.9.9 and before behavior was correct.  Opinions?

Comment 15

[karnaze (gone)]

I took the 1st attachment, added overflow:auto to the tbody, added a row with an
empty cell and all of the extra height went to the last row. So, if the
workaround isn't working, please add it as an attachment (overflow:scroll does
appear to have some problems, but that may be another bug) and reopen the bug.
The workaround's only purpose is to honor the heights of the other rows, it has
nothing to do with scrolling. 

I don't see how this bug has anything to do with scrolling tbodies and still
don't understand why it is more of a problem for scrolling tbodies than for
non-scrolling tbodies. The examples given don't even have enough rows to need
scrolling.

I think the current behavior is more correct that before m1.0. To have a table
with empty space is odd and unique among browsers. If this bug were valid then
we would have to do the same thing for columns. 

->invalid

Comment 16

[Rick DeBay]

Sorry about the tone of comment #13.  It was late and I was upset that I had
worked on this for so long, and now it was tossed.  I'll reply again with
additions to comment #14.

Comment 17

[Rick DeBay]

I just read comment #15.  I think this is a very valid bug given the attachment.
 Given a JSP page containing a table which could have N rows, we want that table
to scroll rather than make the page huge and scroll the page.  This is the
purpose of the scrolling TBODY.  The server has no idea if the height of the N
rows are going to be greater than the height of the table (I hated giving the
table a fixed height [violates accessibility guidelines], but was told by
Mozilla developers that was the only way to get the scroll to work) so we must
always specify a fixed height for the table, instead of letting the table size
the browser to the rows.
Therefore if we are ever to get useful scrolling tables, it will look like cr*p
when there are not enough rows to cause the UA to scroll.  W3 admits that it is
undefined behavior if both table and row heights are specified but don't match.
 The behavior of Mozilla as of 1.0 is not valid IMHO, as it is not honoring the
developers specification for the row height, and from an aesthetics viewpoint
it's ugly.
I want to hear opinions from some of the others on the CC list before I post to
the newsgroups.

Comment 18

[Rick DeBay]

I'm going to try setting the max-height instead of height for the TBODY.  I
didn't do that before, because it caused significant problems.  If max-height
for TBODY has been fixed then the problem outlined by this bug becomes an
intellectual excercise for W3.

Comment 19

[karnaze (gone)]

I don't think max height is implemented yet.

>so we must always specify a fixed height for the table, instead of letting the 
>table size the browser to the rows.

What does it mean to let the table size the browser to the rows? 
 
>Therefore if we are ever to get useful scrolling tables, it will look like cr*p
>when there are not enough rows to cause the UA to scroll.

Why can't you specify a fixed height (or even a percent height) on the tbody
(the table may not even need a height, not sure) and overflow:auto on the tbody.
If you want all of the rows to be the same height then use the workaround I
mentioned. 

I'm still not sure what you are trying to achieve. Could you please attach a
simpler example with just the scrolling tbody and indicate how you want it to look?

Comment 20

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

max-height is certainly implemented for blocks, and I think a bunch of other
things, but it may not be implemented for internal table boxes.

Our implementation of percentage heights is probably nonconformant in that they
work much more often than they should -- according to CSS2 percentage heights
should only act as something other than 'auto' when the parent's height is not
specified exactly: http://www.w3.org/TR/CSS21/visudet.html#the-height-property

Comment 21

[Rick DeBay]

Example: follow these instructions with both IE and Mozilla.

1. Go to the URL listed for this bug.
2. Select the guest login (you will need Javascript and Cookies enabled for the
current version of this site).
3. Go to Plan Activities->Agenda and Plan Activities->Sessions.  With Mozilla,
the TBODY scrolls, for other browsers we use a DIV and the column headers aren't
lined up as well, especially if the window is resized.  Since the rows overflow
the given area, the rows look fine.
4. From the Sessions page, select "Overview of Websphere" (
http://www.expofusion.com/msgsys/sessionInfo.jsp?courseId=611511 ).
5. See how the row heights are stretched for the list of course sessions.

While adding and extra row will work for the case where there are not enough
rows to fill the TBODY, it is still a workaround and not a fix.  As I stated
before, CSS2 doesn't currently address "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."  IMHO the table
height and the content height should be honored, and the unused area filled with
the table background.
Given that there is no direction for this, and CSS2 explicitly points this out,
I believe this should be reopened and futured until CSS resolves this.

>"What does it mean to let the table size the browser to the rows?"
I meant 'browser size the table to the row's(heights).'