Table height percentages wrong for nested tables.

RESOLVED FIXED in mozilla0.9.6

Status

()

Core
Layout: Tables
P3
normal
RESOLVED FIXED
19 years ago
5 years ago

People

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

Tracking

({testcase})

Trunk
mozilla0.9.6
x86
Windows 95
testcase
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

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

Attachments

(5 attachments)

(Reporter)

Description

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.
Status: UNCONFIRMED → 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
(Reporter)

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

Updated

18 years ago
Status: NEW → ASSIGNED
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:
http://bugzilla.mozilla.org/showattachment.cgi?attach_id=3127

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.
http://bugzilla.mozilla.org/showattachment.cgi?attach_id=7628

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.
http://bugzilla.mozilla.org/showattachment.cgi?attach_id=7627

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. ***
(Assignee)

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.
Status: ASSIGNED → RESOLVED
Last Resolved: 18 years ago
Resolution: --- → INVALID

Comment 9

18 years ago
Adding 'verifyme' keyword
Keywords: verifyme
(Reporter)

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.

Dan
Status: RESOLVED → REOPENED
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 
TD.

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

Updated

18 years ago
Keywords: testcase

Updated

18 years ago
Target Milestone: M18 → ---
(Assignee)

Comment 17

18 years ago
Moving to m1.0
Status: REOPENED → ASSIGNED
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?
(Assignee)

Comment 21

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

Updated

17 years ago
Blocks: 97138

Comment 22

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

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. 

Updated

17 years ago
Keywords: nsbranch → nsbranch-
Whiteboard: CANDIDATE_094
(Assignee)

Updated

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

Updated

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

Updated

17 years ago
Blocks: 107067

Updated

17 years ago
Keywords: nsbranch-
(Assignee)

Comment 24

17 years ago
fixed by meta bug 97138.
Status: ASSIGNED → RESOLVED
Last Resolved: 18 years ago17 years ago
Resolution: --- → FIXED
(Assignee)

Updated

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.