88641 - CSS-declared table with height of 100% is not working

Status: VERIFIED INVALID

(Core :: CSS Parsing and Computation, defect)

Description

[Joel Peterson]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.2) Gecko/20010628
BuildID:    2001062815

The page looks wrong in Mozilla, and not in other browsers. The problem did not
exist in Mozilla build 0.9.0, but it has resurfaced since build 0.9.1

I have seen this on other pages too, like my internal development page. Unknown
if this problem exists outside of XHTML 1.0, like HTML 4.0


Reproducible: Always
Steps to Reproduce:
1. Goto this site: http://www.inkvine.fluff.org/~peter/
2. Make sure code is correct to make the table 100% in height
3. Examine height of main table

Actual Results:  The table was not 100% in height.

Expected Results:  The table should be 100% in height.

Comment 1

[Greg Breland]

I can verify that the above URL does not 100% the height of the table in Mozilla
2001063008.  The table is 100% in IE.

However, I can not seem to produce a reduced testcase.  I can not make a table
with a style of "height:100%" not be 100%.

I strongly suspect that Mozilla is rendering correctly and that there is a bug
in the page.  I will attach my failed attempt to reproduce this bug so someone
else can use it as a starting point of a testcase.

Comment 2

[Greg Breland]

Attachment: Failed Test Case

Comment 3

[Joel Peterson]

Thanks for your help, Greg. Are you making sure that in reproducing the test 
case, that is an XHTML 1.0 Strict Page, with the table being a class that has a 
value of height:100%?

Comment 4

[Henri Sivonen (:hsivonen)]

This is a feature of CSS rather than a bug in Mozilla.

"Specifies a percentage height. The percentage is calculated with respect to the
height of the generated box's containing block. If the height of the containing
block is not specified explicitly (i.e., it depends on content height), the
value is interpreted like 'auto'."

http://www.w3.org/TR/REC-CSS2/visudet.html#the-height-property

Comment 5

[Greg Breland]

Just to make it a little clearer for the reporter:

Henri pointed out that the the table is going to have a height of "auto".  The
spec also says that auto is caculated as filling up as much space as it can
bounded by its parent block or by child block elements.  Therefore, Mozilla is
rendering this page correctly.

"If it has block-level children, it is the distance from the top border-edge of
the topmost block-level child box, to the bottom border-edge of the bottommost
block-level child box. Only children in the normal flow are taken into account
(i.e., floating boxes and absolutely positioned boxes are ignored, and
relatively positioned boxes are considered without their offset). Note that the
child box may be an anonymous box."

Comment 6

[Joel Peterson]

I am trying to point out that when page enclosing table is set to 100%, Mozilla 
is generating the page as auto, and not 100%.

I'll read the spec some more to get this right, but the XHTML and CSS is W3C 
compliant, and your test case was irrelevant, since you added the 
class "enclosure" to the last <td>, and also since you did not encode it in 
XHTML.

Also notice how the table is not centered on the page. Same thing happens at 
this XHTML page: http://216.103.86.249/

Comment 7

[Joel Peterson]

I'd also like to add that none of the tables are centered, and some of the 
boxes are not displaying the correct border colors.

This could be a XHTML-specific bug, so please follow up with XHTML test pages 
from now on.

Comment 8

[Greg Breland]

According to the spec, "height:100%" is converted to "height:auto" when the
height of the containing box is not specified, but determined by the content.

The only thing I see in your code that is even trying to center the table is the 
<div class="centre"> 
centre  {text-align:center;}

According to the sec, text-align only applies to inline elements and therefore
will not center the table block element.

I don't see the "wrong border color" problem, but I do see borders that appear
to be too large compared with IE5.5.  I can not figure out shy the top and
bottom <tr> border is soo large.

BTW, I like the Netscape Rant.  That should be in the Mozilla FAQ on why Mozilla
is better than Netscape.

Marking "INVALID" because the main problem "height:100%" on tables are handled
correctly by Mozilla.  Might want to file a seperate bug on the border
color/size problem.

Comment 9

[Joel Peterson]

Well, I got the page looking correctly in IE5 and IE6, but with Mozilla some of 
the borders are not all black, they have grey borders also. There is also a 
problem with the table not accepting its forced height, making my title image 
box looking tacky and wrong.

The page I used in this submission was done by my friend, PeterB. He doesn't 
completely agree with Mozilla's interpretation of the W3C spec [either do I], 
so we're going to read through it and figure out what is really going on.

Is there really a problem on the border color? 

Futhermore, I'm surprised that the W3C validator would pass this code as 
correct, where is displays perfectly in IE, but not Mozilla.

It looked great in 0.9 :|

Comment 10

[Asa Dotzler [:asa]]

style system

Comment 11

[Hixie (not reading bugmail)]

Pages can go through a validator and be syntactically correct, that doesn't mean
it'll do what you think it'll do... for example, if you want to make something
look red, and you say:

   p { color: green; }

...then the validator will say the CSS is perfectly valid, but it will still not
look red.

Anyway, in this case, the page has several things wrong with it that the 
validators won't catch.

The first is that the script is commented out. In HTML, that works, but in 
XHTML, it just results in the section being ignored. This is because in HTML
the <script> block is defined as being CDATA, whereas in XHTML it is not. The
easiest solution around that is to not use XHTML. If you really want to use 
XHTML then I would recommend keeping the script in an external file, like you
do for the other script.

If you don't believe me about the comment thing, tell the W3C validator to show
you the parse tree, and look to see what it thinks the contents of the second
<script> block is.

The problem that this bug mentions, though, is that 'height:100%' isn't giving
you the results you expect. The reason for this is that, as mentioned above,
percentage heights are treated as 'auto' if the parent block doesn't have an
explicit width. In this case, the parent of the table is a <div>, which has
no explicit height. Even if you have the <div>, the <body>, and the <html> 
elements all 'height:100%', you would still not get the effect you want, because
the containing block of the <html> element has itself got an 'auto' height.

The solution is to say:
   .container { position: fixed; top: 0; left: 0; right: 0; bottom: 0; }
...which makes the table take the same space as the viewport.

The other problem mentioned above is that you use 'text-align: center' to try to
align a table (as opposed to text). The property 'text-align' only aligns text
and other inline content like images on a line. The way to center a block is to
give it 'auto' margins, for example, to center a <div>:

   div { width: 100px; margin-left: auto; margin-right: auto; }

Overall, unless you have a very good reason to, I would strongly suggest not 
using XHTML at this stage, unless you serve it as text/xml (thus causing 
browsers to treat it completely as XML and not HTML or tag soup). There isn't
much point in using XHTML since no browsers really support it right now except
Mozilla, and it only supports it if you send it as text/xml; plus, as you have
discovered, there are subtle differences between how XHTML works and how tag
soup is treated by existing web browsers.

If you need references for any of my assertions, feel free to ask.

VERIFIED INVALID.

Comment 12

[Christopher Aillon (sabbatical, not receiving bugmail)]

*** Bug 93052 has been marked as a duplicate of this bug. ***

Comment 13

[Joel Peterson]

Ian your solution does not fix the page. Adding the container field to the main 
table does nothing.

Also, I can not figure out why all of the elements are off center, but 
perfectly aligned in IE. Can you explain that? I am following standards 
HTML/XHTML procedures, yet Mozilla is mangling everything.

Comment 14

[Hixie (not reading bugmail)]

Joel: Have you fixed the page to correct all the mistakes I mentioned above?

Comment 15

[Joel Peterson]

Yeah. Seriously, I gave it a lot of time making sure the code was just right 
and to standards. Finally got it done, and it still looked terrible in Mozilla, 
and made it look bad in IE, so I put it back.

I made table have this class:
.container { position: fixed; top: 0; left: 0; right: 0; bottom: 0; }

It did nothing.

I'll work more on aligning things with the example you mentioned. Problem is, 
once I have a table centered, every single element inside of it [text] is 
centered unless I specify it otherwise. That's extremely annoying.

I'm sure I'll figure it out in the end, or just no support Mozilla. I'm not 
even going to go with Netscape 4.x support. There's no way I'm going to add 
scripts or parts to my code just for one browser when the others don't even 
need it. :\ The code will either look right in all the browsers I'm concerned 
with, or just in IE if I can't get it to look right in Mozilla without messing 
it up in IE.

Comment 16

[Hixie (not reading bugmail)]

Joel: send me mail ([e-mail]) with your page's address, and I can take a 
closer look.

Comment 17

[Greg Breland]

Joel, be careful about using bugs on a piticular browser as a major visual piece
of your page.  Just because IE5.x, IE5.5, IE6.0 work does not mean that
Microsoft will not fix it in IE6.1, 6.5 or 7.0.

This is the main reason I develop all my code to work with IE/Mozilla.  No one
but myself uses my corprate Intranet pages on anything other than IE.  However,
makeing sure my code works in both browsers keeps browser specific bugs out of
my code that will hurt me latter on.  Most of my intranet systems will be in use
at a company for 5-10 years.  Must think to the future.  

It works both ways though, if I coded only to mozilla, then I would have many
Mozilla specific bugs.

Comment 18

[Josh Birnbaum]

*** Bug 201328 has been marked as a duplicate of this bug. ***