Finally people are catching onto my biggest complaint with CSS

Mark Pilgrim links to Steven Canfield's post entitled CSS: Where art thou? (Height: Auto), and writes:

I have absolutely no idea if it's possible to replicate <table height="100%"> in CSS, but I'd be very interested to find out.

Mark, I sent you an e-mail almost exactly a year ago explaining this exact problem. At the time I made a weblog post claiming that CSS can't replace tables for layout, where I proved it with examples. Now with all the debate about CSS, it seems that some of the flaws inherent in CSS are starting to be recognized, besides all the browser incompatibilities that, while pains in the ass, don't by themselves mean that CSS itself is broken.

Steven writes:

But, [CSS] has problems. Unwarranted departures from HTML, on a whim perhaps. Today, I worked on this example: In HTML, I can declare a tables height to be 100%. It will be 100% of the height of the page (or whatever contains it). In CSS, I can also declare the height of something to be 100%. The difference? CSS runs up the tree, asking the parent what it's height is. If the parent has no height, that is, height:auto (the default), then the child says "100% of nothing is nothing!".
height:auto does not mean nothing. It means, "I've got content, and it's going to fill me up to some unknown height." The rationale for this is that height:auto determines it's height by asking its children, and you don't want to get into an inifinite loop there.

That may be a little confusing. Let explain how I look at it. Every element in an HTML page has some size on the screen. That size is either specified explicitly using some type of "absolute" measure (inches, centimeters, pixels, etc.), or it is specified in a way that is relative to the "block" of HTML it's contained within. There are a whole bunch of complicated rules as to how this is actually supposed to work, but the point that's important for the discussion is that elements that don't explicitly say how big they are get a computed width and computed height on the screen relative to what that element is contained within.

Here's the issue. You say "width: 100%" and it makes the element 100% of the width of whatever it's contained within. You say "height: 100%" and it ignores you, instead choosing to make the height dependent on whatever content happens to be in that element. This is inconsistent and broken.^[1]

What's the problem? Tables have been working the way you'd expect forever, right? If you make a three column layout with a table, and the center column has more content than the right and left columns, the right and left columns happily continue down to reach the bottom of the table. If the right and left columns have a background color, for instance, the color continues to the bottom with no problem. See this for an example of what I mean (sorry for the ugly colors). This is what happens with CSS, and there's no way around it because it's specified that way in the spec. Both of those two examples I showed you are pure CSS, with no tables. The only difference is that the first one has an explicit height set for the containing <div> and the second one doesn't.

I sent an e-mail to Bert Bos, the maintainer of the CSS 3 Box Model spec, about 11 months ago, explaining this problem. I never got a reply. I was hoping the W3C, as a standards body, would be open to public criticism and suggestions, but I suppose not.

Footnotes:
[1]: For details, see the width property and the height property. The killer language in the height property is this: "If the height of the containing block is not specified explicitly (i.e., it depends on content height), the value is interpreted like 'auto'.". So, even though you told it you wanted 100% of the height of the containing block, it says no. The language for the width property is simply "The percentage is calculated with respect to the width of the generated box's containing block."

Permalink | 7 Comments | Tags: Programming | id 3853

20:29 (utc-4)