176346 - percentage height inside P block does not work as expected

Status: RESOLVED DUPLICATE of bug 88035

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

Description

[David W. Jeske]

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

Comment 1

[Gérard Talbot]

Can you use a more recent build and verify if the problem you see is still there?
ftp://ftp.mozilla.org/pub/mozilla/nightly/latest/

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

Comment 2

[Boris Zbarsky [:bzbarsky]]

Of the two problems mentioned on that page I only see the second one
(overflow:scroll).

Comment 3

[David W. Jeske]

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.

Comment 4

[Boris Zbarsky [:bzbarsky]]

OK.  confirming it for the overflow:scroll thing (which I do see)... The other
problem could maybe be resolution-dependent rounding error...

Comment 5

[David W. Jeske]

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

[Gérard Talbot]

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

[David W. Jeske]

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

[Gérard Talbot]

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

[David W. Jeske]

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:

  http://mozart.chat.net/~jeske/Projects/Mozilla/bugs/5.html

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

  http://mozart.chat.net/~jeske/Projects/Mozilla/bugs/6.html

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

Comment 10

[David W. Jeske]

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:

http://mozart.chat.net/~jeske/Projects/Mozilla/bugs/7.html
http://mozart.chat.net/~jeske/Projects/Mozilla/bugs/8.html

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.

Comment 11

[Boris Zbarsky [:bzbarsky]]

This is not unspecified territory.  Per CSS spec (and ignoring the invalid HTML),

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

Should render identically to:

<p>
<table></table>
</p>

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

[David W. Jeske]

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

[Madhur Bhatia]

Attachment: another testcase

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

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
property-value 

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

Comment 14

[Boris Zbarsky [:bzbarsky]]

> 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 http://www.w3.org/TR/CSS21/visudet.html#propdef-height carefully
(especially he part about percentage heights inside auto heights).

Comment 15

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 112907 [details]
another testcase

not a valid testcase for this bug.

Comment 16

[Madhur Bhatia]

ahhh!!!!
got that... thanks Boris :-)

Comment 17

[David W. Jeske]

Attachment: Illustrates the bug, case 1

Comment 18

[David W. Jeske]

Attachment: test case for the bug

Comment 19

[David W. Jeske]

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

Comment 20

[Eli Friedman]

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.

Comment 21

[Boris Zbarsky [:bzbarsky]]

> Does the quirks mode rendering need to be different

Yes.

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 ***