268134 - div tag refuses to size relative to its parent table (John Carroll - bah humbug - ZDNet)

Status: RESOLVED INVALID

(Core :: Layout, defect)

Description

[David A. Wheeler]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031016
Build Identifier: 

Author John Carroll wrote a complaint about Firefox; this is the specific bug he
noted: 'I have created a Web page with a fixed position left, top and bottom
sidebar that surrounds a scrollable area. All regions resize to completely fill
the browser when its dimensions are changed. To make this work, I have a table
which lays out the basic position of the main sections (left bar, top bar,
bottom bar, content). I’ve placed a div tag inside the "content" area of the
table, setting its width and height to 100% and adding automatic scrollbars by
setting the "overflow" CSS attribute to "auto."
None of this is rocket science. Some might object to the use of tables, which in
CSS circles might seem SO 1990s. I couldn’t care less. Tables are easy to use,
are immediately intuitive to this old HTML hand-coder, and most important, have
existed since the early days of HTML. Regardless of your preferences, there is
no reason they SHOULDN’T work.
In IE, the page renders properly. In Firefox, the div tag refuses to size
relative to its parent table (and doesn’t provide scrollbars), which causes the
bottom toolbar to disappear past the edge of the screen.'
A specific HTML page that demonstrates this is at:
http://www.turtlenecksoftware.com/bah-humbug.htm
(Note: I didn't find this bug; I just wanted to make sure it's in the Bugzilla
system.  I didn't find a related bug, if so, please link to it so that those who
search for "Caroll" or "humbug" can find this).


Reproducible: Always
Steps to Reproduce:
View: http://www.turtlenecksoftware.com/bah-humbug.htm

Actual Results:  
Per Carroll: "In Firefox, the div tag refuses to size relative to its parent
table (and doesn’t provide scrollbars), which causes the bottom toolbar to
disappear past the edge of the screen."


Expected Results:  
Per Carroll: "I have created a Web page with a fixed position left, top and
bottom sidebar that surrounds a scrollable area. All regions resize to
completely fill the browser when its dimensions are changed."

Comment 1

[Martijn Wargers (dead)]

Well, something like that can be accomplished in Mozilla by using:
#scrollRegion
{
	overflow: auto; 
	position:absolute;
	bottom:40px;
	top:40px;
	right:0;
	left:60px;
	padding:10px;
}
in the css.

See example:
http://home.hccnet.nl/m.wargers/test/mozilla/bah-humbug.htm

It would be even more convenient if position:relative for table cells would be
supported (bug 35168).

Afaik, the current way he tries to do this, is not the right way.
Height:100%;width:100% as css in #scrollRegion takes the height/width of the
viewport in Mozilla (which is the right way, I think), but in IE it takes the
width/height of the table cell it is positioned in.

Comment 2

[Eric Seynaeve]

Could this be caused by the following in the specs
(http://www.w3.org/TR/REC-CSS2/tables.html#height-layout):
"In CSS2, the height of a cell box is the maximum of the table cell's 'height'
property and the minimum height required by the content (MIN). A value of 'auto'
for 'height' implies a computed value of MIN. CSS2 does not define what
percentage values of 'height' refer to when specified for table cells."?

The height:100%; in the #scrollRegion should refer to it's containing block
which, IMHO, is the table cell. According to the above quote, that value should
be the minimum size to display all content since no fixed height is defined for
the table cell. Trying to set the width and height of #scrollRegion to a fixed
value (px or em) gives the expected scrollbars.

Am I correct in this analysis?

Comment 3

[Martijn Wargers (dead)]

Well, afaik, this part of the css2.1 spec applies:
http://www.w3.org/TR/CSS21/visudet.html#the-height-property
See: <percentage> text:
"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), and this
element is not absolutely positioned, the value is interpreted like 'auto'. A
percentage height on the root element is relative to the viewport."

The "containing block" term is defined here:
http://www.w3.org/TR/CSS21/visudet.html#containing-block-details

So in this instance, the containing block is the table cell. This table cell has
no specified height, so the value is interpreted like 'auto'. 
So the height of #scrollRegion becomes auto. That means the height becomes as
big as the content it has in this instance,which is a lot (so #scrollRegion
doesn't take the height of the viewport like I said in comment 1). 

Comment 4

[Boris Zbarsky [:bzbarsky]]

Martijn is right.  This is invalid.  IE's handling of percent heights is
notoriously buggy.

Comment 5

[Martijn Wargers (dead)]

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

Comment 6

[Olivier Cahagne]

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