percentage height inside P block does not work as expected




Layout: Tables
15 years ago
14 years ago


(Reporter: David W. Jeske, Unassigned)



Firefox Tracking Flags

(Not tracked)




(2 attachments, 1 obsolete attachment)



15 years ago
User-Agent:       Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; T312461; .NET CLR 1.0.3705)
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826

When a DIV with relative width or height style paramaters (i.e. 
STYLE="width:50%;height:50%") is nested inside a table, the layout is broken in 
Mozilla. For details, please view the URL provided.

Reproducible: Always

Steps to Reproduce:
view the URL provided (or any page with a DIV which has percentage width or 
height specified in the STYLE, which is also nested inside a table).

Actual Results:  
The rendering is wrong.

Expected Results:  
Mozilla should have rendered percentage sized DIVs correctly even inside table 

Comment 1

15 years ago
Can you use a more recent build and verify if the problem you see is still there?

I checked your page with build 2002102308 using XP Pro SP1 and saw nothing wrong
(except the first case Non-nested div where a height percentage should refer to
the document and not to the viewport.. and this is already filed in another
Of the two problems mentioned on that page I only see the second one

Comment 3

15 years ago
I just installed the "latest" build (2002102308) on Win2k.

Both the "DIV nested in Table" and the "DIV nested in Table w/overflow:auto"
examples render INCORRECTLY for me in Mozilla.

The "DIV nested in Table" example is missing the top and bottom borders. I only
see the red lines on the left and right borders but they should be on all borders.

The example "DIV nested in Table w/overflow:auto" is still rendering as a fixed
height DIV and not stretching to fill the table cell. You may been to make the
viewport bigger to see the problem.
OK.  confirming it for the overflow:scroll thing (which I do see)... The other
problem could maybe be resolution-dependent rounding error...
Ever confirmed: true

Comment 5

15 years ago
There seems to be an intermittent behavior which may have obscured the problem
in the "overflow:auto" case. The first time I viewed the page it was broken, but
then it fixed itself. 

I created a new example which is repeatable and shows the problem for me. It
occurs when both the TABLE and the DIV are using percentage based height.

As I mentioned in my last note, the other examples are also slightly broken in
that their top and bottom borders are missing or obscured. However, they are
much better than in the last build I was testing with.

Comment 6

15 years ago
re: comment #3

- DIV nested in Table: I do not see the top and bottom borders either. But the
DIV  fills the vertical space and half of the horizontal space. 

- DIV nested in Table w/overflow:auto: I do not see the top and bottom borders
either. But the DIV  fills the vertical space and half of the horizontal space.
(When I first saw this page, this example was different).

-  DIV w/overflow:scroll nested in Table causes table HEIGHT to collapse: 
<table WIDTH="50%" HEIGHT="80%" BORDER=1> is in the source code. Height is not a
valid HTML 4 attribute of table, even in transitional DTD. (And in case
style="height:80%;", it would have to be 80% of the document's height, not 80%
of the browser's viewport: I believe there is a bug for that one.)

XP Pro SP1, using 2002102308

Comment 7

15 years ago
Regarding HTML4: Changing it to a height style instead of a height attribute 
still results in the same bad render of the table and the embedded DIV. 

Regarding viewport-size vs. document-size: I don't understand why it would be 
document size. If a TABLE is the only element in a document and its height is 
set to 100%, what is the document-size? IE treats this as a percentage of the 
viewport size, and it's most common usage is to make a TABLE expand to fill an 
entire viewport when it's smaller than the viewport. 

HTML4 or not, setting a table to HEIGHT=100% currently works fine in Mozilla. 
However, an embedded DIV set to height:100%; inside the table does not expand 
to fill the table cell as it should.

Comment 8

15 years ago
I guess I somewhat got confused with bug 105346: anyway, I think CSS2 section
10.6.3 should apply here regarding css property height %tage.

Comment 9

15 years ago
I have updated my test URL to use the CSS2 style height and width for the table 
instead of attributes. It still produces broken Behavior in today's build:

Oddly, this simple test case with ONLY a table and div in the document DOES 
work correctly:

I am working to try and isolate what causes the problem with 5.html.

Comment 10

15 years ago
I believe I have found root-cause for this problem, and I have changed the
summary to:

  percentage height inside P block does not work as expected

While this is probably in "unspecified territory" and not a CSS2 implementation
bug, it's possible that this is responsible for other subtle layout problems
with Mozilla on real-world pages.

Here are two examples which render "well" on IE and "poorly" on Mozilla because
of this problem:

This problem is exacerbated by the habit of creating open P blocks, because once
you open a P block, percentage based heights will no longer work for contained
elements in Mozilla. The IE developers seem to have handled this and made
percentage heights do some "sane" things even when inside P blocks.
Summary: DIV percentage width or height style broken when nested inside a table cell → percentage height inside P block does not work as expected
This is not unspecified territory.  Per CSS spec (and ignoring the invalid HTML),

<table style="height: 100%"></table>

Should render identically to:


because the height of <p> is auto.

I suggest doing some tests in standards mode in addition to the quirks-mode
tests we have here.... There may well be a difference.

Comment 12

15 years ago
I just found and filed bug 176550, which is related to the problem here, but
different enough to warrant a new bug filing. 

Comment 13

15 years ago
Created attachment 112907 [details]
another testcase

This testcase shows that the height property given a percentage value does not

Here, i have a DIV element with style "height : 50%" (this should have height
50% of the viewport)
There is a P element contained with the DIV also given the styel "height : 50
%" (this should have height 50% of it's containg block)

Even when i resize the window, i do not see the correct rendering of the

Actually, this renders the same way in IE, too.


15 years ago
Keywords: testcase
OS: Windows 2000 → All
Priority: -- → P3
> this should have height 50% of the viewport

It should not.  It should have height:auto (since this is standards mode).

> this should have height 50% of it's containg block

It should have height:auto.

Good to know IE doesn't fuck this up.

Please read carefully
(especially he part about percentage heights inside auto heights).
Keywords: testcase
OS: All → Windows 2000
Priority: P3 → --
Comment on attachment 112907 [details]
another testcase

not a valid testcase for this bug.
Attachment #112907 - Attachment is obsolete: true

Comment 16

15 years ago
got that... thanks Boris :-)
OS: Windows 2000 → All
Priority: -- → P3

Comment 17

15 years ago
Created attachment 113205 [details]
Illustrates the bug, case 1

Comment 18

15 years ago
Created attachment 113206 [details]
test case for the bug

Comment 19

15 years ago
These examples which were in Comment #10 are simple and valid test cases of for 
the bug, so I attached them.


15 years ago
Target Milestone: --- → Future

Comment 20

14 years ago
None of the testcases for this bug are in standards mode.  Does the quirks mode
rendering need to be different, or is there a standards mode bug not illustrated
here?  In standards mode, everything appears to be rendered correctly.
> Does the quirks mode rendering need to be different


In any case, the overflow issue seems to be no more, the top and bottom borders
being obscured is a necessary consequence of the CSS box model, and all the
collapsing cases (and the original bug as filed) have been fixed by the checkin
for bug 222730 / bug 88035.

*** This bug has been marked as a duplicate of 88035 ***
Last Resolved: 14 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.