Keith Devens .com

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)

Comments

It is true that this is one of the major limitations of CSS. As usual, there is a workaround which can get the background colour of those left and right hand side columns to extend to the bottom of the divs: Set a background image on the body tag which is a line of background colour as wide as the left hand column, then create a similar image as wide as the right hand column and set it as the background on a "container" div wrapped around the rest of the document. It works, with a bit of tweaking, but it means the width of both columns must be specified in pixels rather than a relative unit such as percentages or ems.

I agree, the CSS box model really needs to address this. You could try starting a thread on the www-style mailing list, which is where all such issues are meant to be publically discussed.

Even if CSS has its errors it doesn't mean we should go back to tables! You mention that it's not just the browsers that are stopping CSS from being properly implemented, but the fact that CSS has issues that are seriously flawed.
But, I'd like to put forward the point of view that CSS is only still flawed because of the browsers not treating it properly. If NN4 and IE5.0 and all the rest had supported CSS 1 & 2 properly, then there would be a lot less confusion over how exactly css should be displaying things. People would be able to then see exactly what css should do without having to decipher the w3 spec. Then the bugs would be more evident, and would be easier to fix. As it is, even if the W3 decide to change height: 100%; to something more sensible, Internet explorer won't catch up for a few years, and even when it does it'll still take most people a few more years to upgrade.
Whatever the issue is with css, you can be sure that msie can take a least some of the blame

Dan, you're right. There is no height attribute on tables. I just checked, and it does work if you use it, but it's not standard. I actually wondered about that when Steven referred to it, but I didn't question it because his main point still stood.

Therefore CSS hasn't actually broken anything, it's actually gone and added something

You're right, in that standard HTML doesn't provide a way to make an element fill a percentage, height-wise, of the page. And you're right that CSS has added a lot. But my point is that the spec is inconsistent, and in that sense "broken". It's broken further in that layouts we could do with tables, because a row would always be 100% of the height of the table (if there was only one row), we can't do anymore with table-less pages using just CSS for layout.

My premise all along has been that there's no technical limitation to making the height behave how we expect. I just tried a layout similar to what I tried to do in CSS, but with nested tables, and it came out the same way the CSS would have. So, it's totally possible that there is a technical limitation, and the spec writers actually got it right (they are very smart people after all), but I haven't heard an argument as to what the technical limitation is. Furthermore, when I was first researching this and was asking around in #mozillazine, people there thought it wasn't a technical limitation.

Tuesday, May 6, 2003

Finally people are catching onto my biggest complaint with CSS

Comments

Recent comments