Table height percentages wrong for nested tables.

RESOLVED FIXED in mozilla0.9.6



Layout: Tables
19 years ago
5 years ago


(Reporter: Dan203, Assigned: karnaze (gone))



Windows 95
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)


(Whiteboard: [awd:tbl] CANDIDATE_094, URL)


(5 attachments)



19 years ago
When a table is nested inside of another table, and it's height is set to a 
percentage it reacts sporadically depending on the height and content of the 
parent table (see examples).

Comment 1

19 years ago
Looks like a bug.  Changing to NEW.
Ever confirmed: true

Comment 2

19 years ago
Actually, according to the HTML spec, there is no HEIGHT attribute to the TABLE
tag.  NS 4.7 ignores the HEIGHT attribute and renders all three example tables
the same.  Mozilla should nevertheless decide what it wants to do with the
HEIGHT attribute and either expand the table to the full height of the
containing cell or ignore the HEIGHT attribute.
Severity: critical → normal

Comment 3

19 years ago
Actually Netscape 4.x does not ignor the height attribute!!! If you set a 
non-nested tables height to 100% Netscape 4.x renders it correctly (minus the 
fact it allways thinks there are scrollbars on the screen). This is not just a 
HTML problem either. If you set the height attribute in a style sheet instead it 
produces the exact same result. When using the height style this bug also 
effects fieldsets (and proably other elments I haven't tested yet). I think 
people expect both the height attribute and the height style to react the same 
and cause the elemnt to fill all available space of the table cell. IE4 and IE5 
both render this page correctly.


18 years ago
Target Milestone: --- → M18

Comment 4

18 years ago
Some testcases:

From bug 19526, '"HEIGHT" option in <TABLE>', tables with %-based HEIGHT inside 
an outer table with %-based HEIGHT appear to work properly:

From bug 35945, "nested table percent height is not calculated correctly", 
tables with 100%-HEIGHT inside an outer table with px-based HEIGHT appear
to be the same height as specified for the outer table even if the outer table
is taller because of its contents. This is arguably correct, but perhaps the 
inner tavble should be the same height as the outer table actually is.

Also from bug 35945, if the outer table has no height set, a 100%-height
inner table is only as tall as its contents. It would make sense that this 
table would be the same height as the intrinsic height of the outer table.

Both of the latter testcases were coded in HTML+CSS.

Comment 5

18 years ago
Is this the same bug as bug 18440?

Comment 6

18 years ago
That test case looks like one of those things optomologists use while trying to 
get your eyeglass prescription right.  "On which side is the text more clear, 
on the green or on the red?"  I'll venture "green".

Comment 7

18 years ago
*** Bug 37439 has been marked as a duplicate of this bug. ***

Comment 8

18 years ago
I think Nav4.7 and 6.0 have got this right. The nested table's containing block 
(for percentage calculations) is the cell not the outer table. The cell 
contiaining the nested table does not have a height specified so the nested 
table is only as high as it needs to be. Marking invalid.
Last Resolved: 18 years ago
Resolution: --- → INVALID

Comment 9

18 years ago
Adding 'verifyme' keyword
Keywords: verifyme

Comment 10

18 years ago
I disagree! A cells height is governed by the hight of the table that contains 
it, and a tables height is governed by it's content so there is no way to know 
ahead of time what size either a table or cell will be to set their height 
values explicitly. What I think needs to be done is that the tables height needs 
to be a calculate value rather then an explicit value when either of the 
following occur...

1) The tables height is forced larger then the value set in the height attribute 
by it's content.

2) The tables height attribute is omitted or invalid.

I believe this would fix all the problems I've demonstrated in my example and 
should not introduce any other rendering issues.

Resolution: INVALID → ---

Comment 11

18 years ago
Sorry for the spam...

Comment 12

18 years ago
*** Bug 50472 has been marked as a duplicate of this bug. ***

Comment 13

18 years ago
*** Bug 50472 has been marked as a duplicate of this bug. ***

Comment 14

18 years ago
From bug 50472:

Using CSS, height:100% (or any other percentage) doesn't work on a table that 
is nested inside another, and the height is not specified directly on the outer 

This sounds like a wrong interpretation of this quote from the CSS2 spec:
"If the height of the containing block is not specified explicitly (i.e., it 
depends on content height), the value is interpreted like 'auto'."
This sentence contradicts itself a little bit. 'not specified explicitly' is 
not the same as 'depends on content height'.

Current practice in other browsers (i.e. IE) is:
"If the height of the containing block depends on content height, the value is 
interpreted like 'auto'."

The attachment should make things clearer.

Comment 15

18 years ago
Created attachment 13579 [details]
More examples of what's happening, hope this helps...

Comment 16

18 years ago
Created attachment 16867 [details]
Another example, showing this bug with only a single table


18 years ago
Keywords: testcase


18 years ago
Target Milestone: M18 → ---

Comment 17

18 years ago
Moving to m1.0
Target Milestone: --- → mozilla1.0

Comment 18

18 years ago
QA contact update
QA Contact: chrisd → amar

Comment 19

18 years ago
Created attachment 28903 [details]
another example using a nested table, percentage values only

Comment 20

17 years ago
Created attachment 46506 [details]
Another testcase - is this the same issue?

Comment 21

17 years ago
Created attachment 47498 [details]
test with table nested 3 levels - IE fails


17 years ago
Blocks: 97138

Comment 22

17 years ago
adding nsbranch keyword since %height in the nested tables are commonly used..
Keywords: nsbranch

Comment 23

17 years ago
I didn't nominate this as nsbranch, because bug 97138 which fixes it, is quite 
large and has some risk associated with it. 


17 years ago
Keywords: nsbranch → nsbranch-
Whiteboard: CANDIDATE_094


17 years ago
Target Milestone: mozilla1.0 → mozilla0.9.6


17 years ago
Whiteboard: CANDIDATE_094 → [awd:tbl] CANDIDATE_094


17 years ago
Blocks: 107067


17 years ago
Keywords: nsbranch-

Comment 24

17 years ago
fixed by meta bug 97138.
Last Resolved: 18 years ago17 years ago
Resolution: --- → FIXED


16 years ago
No longer blocks: 97138
Depends on: 97138
mass remove verifyme requests greater than 4 months old
Keywords: verifyme
You need to log in before you can comment on or make changes to this bug.