CodeBitch : click here to go to MacEdition Homepage
 

Turning the Tables

30 October 2000

I’m a big fan of standards support and Cascading Style Sheets. But I find it impossible to satisfy the most doctrinaire standards advocates. I’d like to be able to use only structural markup and avoid any hint of presentational markup. I’d like to be able to have MacEdition’s pages conform to HTML 4.0 Strict instead of HTML 4.0 Transitional. But I just can’t do it. So instead, I risk the wrath of markup purists everywhere and use tables for layout.

I’d love it to be otherwise. Browsers generally wait until they’ve received an entire table before rendering it. It’s a good way to break your readers’ concentration by making them wait. And it would be so nice to just use a few DIV tags with id or class attributes to define the layout. That would be a fast site for users and one that is easily redesigned. You want your sidebar on the right, not the left? Just edit one stylesheet!

But it’s just not feasible with current browsers. Even with IE5/Mac, CSS positioning often turns out to be What You See Is Nothing Like What You Expected. This might be why so many of the pages of markup purists have a linear, vertical structure, with little use of the horizontal dimension in their layout.

Cascading Style Sheets were an inspired, comprehensive solution to the mess of meaning and formatting that HTML had become by the mid 1990s. You can do so much more with CSS than with FONT tags and other obsolete bits of HTML: borders and backgrounds on paragraphs, “hilighter” backgrounds when you hover over a link; colored strips down the side of a page without needing to use the old 2000-pixels-wide background image trick. You could even get rid of some frames if more browsers supported the position:fixed; attribute.

But the CSS positioning capabilities in current browsers just aren’t up to any but the simplest layouts. And if my reading of the specs is correct, the situation won’t get much better even with full CSS2 support.

If you’re wondering how to do a sidebar in CSS, the trick is to have a one-pixel-tall graphic that’s as wide as the sidebar you want. Set the style on the BODY to be {background-image: url('yoururl/yourgif.gif'); background-repeat: repeat-y;}. Then put your sidebar in a DIV with the float:left property and the same width as the picture. The body text should also go in a DIV, with the float:right; property. This stops it from wrapping around the bottom of a short sidebar into the colored zone. For a right-hand sidebar, you also need the background-position: top right; style defined on the BODY tag. (Note you can’t do a right-hand colored strip without CSS.)

In theory, you should also be able to do this just with the floated DIVs without the graphic. But in IE5/Mac, floated DIVs seem to inherit their height from the window size, not the BODY size. You can set the sidebar DIV to have height:100%, but if your sidebar content is more than the user’s screenful, the end disappears. If you omit the height style, the sidebar ends at the end of its content. That’s ok if you want a finite sidebar pallette, but the colored-strip look just can’t be done this way in existing browsers.

Netscape 6 PR2 at least expands the height of the sidebar DIV if the content is longer than a screenful. But if the body content is all short lines, such as a list, the right-hand DIV will float all the way out to the right side of the window, leaving an unsightly gap down the middle.

Sometimes, on a weekend, I’ll have another go at trying to redesign MacEdition’s page layout using just DIVs and CSS, even though I know I could never implement it given the current browser population. It doesn’t work, not even in IE5/Mac. There just doesn’t seem to be a way to say, “I want two regions side by side. The left-hand one should be X pixels wide. The right hand one should fill the rest of the screen. They should be the same height, even if there isn’t enough content in one to match the size of the other.” Even wrapping two DIVs inside a parent DIV doesn’t do it: a parent DIV’s height is no longer determined by those of its child elements if they have been floated. (There is a workaround involving zero-height <br> tags, but that’s an unattractive kludge)

On the other hand, it’s not only browsers that have problems with non-tables-based layout, as anyone who’s ever tried to run text around a graphic in Word will know. Take heed, W3C: future versions of CSS need to learn from Word’s mistakes.

In particular, what I would like to see is the ability to specify some sort of relationship between sibling elements. If I put two DIVs inside a parent DIV, I want to be able to specify that they should be the same height, even when I don’t know what that height is, and even when they are floated. I want to be able to specify that two sibling elements together fill their parent’s width. I want to be able to specify that their widths are in particular proportions to each other, or that one has fixed width and one fills the remainder of the parent’s width. And I want parent DIVs to expand to encompass their floating children if I define them that way, not because I did a kludgy fix. You can do this with frames in relation to the window size, so why not elements in a given page?

Table layouts allow you to do all these things. Until these things are added to CSS, table-based layouts are here to stay.

— CodeBitch (codebitch@macedition.com) is the grumpy cow who does the HTML production for MacEdition.

E-mail this story to a friend