Posted by Pad on May 26th, 2009

All you rock-star cascading style sheet developers who can create insanely complex page layouts: look, I’m happy for you. Really. What you can do is cool. But this article is intended for the rest of us, those who still regularly feel the pain of trying to get those columns to line up correctly.

Internet Explorer 8 and cascading style sheets

Windows Internet Explorer 8 has vastly improved support for cascading style sheets. And that changes everything. Internet Explorer 8 offers full support for CSS2.1, which means the current version of every major web browser in the world now supports CSS2.1.

Let’s review

The point of cascading style sheets is to separate content from presentation. This is a good thing for a number of reasons, foremost of which is that most sites change content frequently, change presentation rarely, and almost never change both at the same time.

If content and presentation are heavily intertwined, adding new content to a site—and making the new content look like it’s part of the same site—can be a lot of work. Changing the theme of an entire site whose presentation is embedded in the content can be…challenging. Challenging enough to make you want to chuck the whole site and completely start over.

There’s an easier way

In properly decoupled sites—sites in which content and presentation are handled separately—content is defined by the HTML elements in the HTML pages, and presentation is defined in external style sheets. Adding new content is nearly as easy as adding plain text. Changing the site theme, instead of editing each page by hand, is as easy as updating the style sheet.

Tables

Remember the bad old days of the web, when your only structured layout choices were frames and tables? Yeah, we’re not even going to talk about frames.

Which pretty much just leaves tables.

About now, all of the semantic-web purists are screaming, “NOOOO!!!” and all of the pragmatists are saying, “Hey, all right!”

So, allow me to elaborate a bit.

Using an HTML table for layout is like using a car for an anchor; it works, but it’s wrong. For the purposes of this post, tables are just wrong for layout (unless what you’re laying out is a table).

But as wrong as they are, they’re about the only way to create an actual grid-based layout. And you can even make it scalable—what we cool web designers like to call a “liquid layout.”

So why are tables bad? Anyone who’s ever had to rework a table-based site already knows the answer to that.

For the rest of you, here’s an analogy. Imagine that you own a book. You’ve written your name on every page of the book (because, hey, it’s your book, right?). Now imagine that you want to sell the book. Just for fun, let’s say you’re selling it to a guy named Steve. The problem is that your name is not Steve. And Steve’s not too keen about having your name on every page of his book. At this point, you have two choices: You can either a.) throw the book away, get a new copy, and sell that to Steve—probably at a loss (start over with a new site design), or b.) erase your name from every page and write in Steve’s name (hand-edit every page).

That was really awful. All that site rework, I mean, not the analogy.

Just imagine, if you had had a magical book controlled by a cascading style sheet, you could have done all that work by changing just one page (probably in an appendix), and then that change would have automatically appeared throughout the book!

Hey, that wouldn’t so bad.

Cascading Style Sheet Layout Pain

So okay, cascading style sheets are great, but they’re hardly perfect. The thing about cascading style sheets up through CSS2.1 is that they mostly deal with content in chunks. Cascading style sheets are really good at taking content, bundling it into chunks, and then stacking the chunks.

And though cascading style sheets generally get the order of the chunks correct, where they sometimes stop making sense is when you try to get those chunks to show up where you want them to show up. (Unless you use absolute positioning for everything, but then your site doesn’t scale gracefully to different browser window dimensions—which you care about if you want people to able to view your sites on a phone or other mobile Internet device. And you do. Well, most of you do.)

Anyone who has ever struggled with columns knows exactly what I’m talking about.

The display: table Property to the Rescue!

Don’t get alarmed by the use of the word “table” in conjunction with layout. The CSS property we’re going to invoke is actually the display property.

Here’s your basic three-column layout with header and footer:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
  "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html dir="ltr" >
<head>
<title>Title</title>
<meta content="text/html; charset=utf-8" http-equiv="content-type" />
<link href="three-column.css" rel="stylesheet" type="text/css" />
</head>
<body>
<div id="header">Header text</div>
<div id="main">
   <div id="left_col">Left column text</div>
   <div id="right_col">Middle column text</div>
   <div id="page_content">Page content text</div>
</div>
<div id="footer">Footer text</div>
</body>
</html>

For reasons already mentioned, we want a liquid layout, rather than fixed positioning. And we’d rather not have to rely on JavaScript. A typical cascading style sheet for a liquid layout would probably contain something like the following:

#header {
}
#container {
  width: 100%;
}
#left_col {
  width: 20%;
  float: left;
}
#right_col {
  width: 20%;
  float: right;
}
#page_content {
  width: 60%;
  float: left;
}
#footer {
  clear: both;
}

This works well enough, except in cases where we need different background colors or borders. Then things get kind of ugly. The problem, of course, is that each column is only as tall as the content it contains; we make all three of them look the same height by using float for the columns and clear for the footer. However, using background colors or borders reveals the column height differences in painfully embarrassing ways.

If we use the display: table property instead of float and clear, the cascading style sheet would look like the following:

header {
}
#main {
  width: 100%;
  display: table;
}
#left_col {
  width:20%;
  display: table-cell;
}
#right_col {
  width:20%;
  display: table-cell;
}
#page_content {
  display: table-cell;
}
#footer {
}

The difference when the page is displayed is that each of the three columns is actually the same height. This becomes even more apparent when you add background colors or borders.

How Is That Different from Using HTML Tables?

First and foremost, display: table is not an HTML tag, it’s a CSS display property. If you have qualms, remember that you’re not creating an actual table; you’re just applying a style.

Where HTML table elements imply semantic meaning (and take too long to load, more or less throw accessibility out the window, and do very unpleasant things to search engine optimization), all we’re doing here is applying cascading style sheet rules to semantically correct HTML div elements.

It still feels like a hack

This is not a hack. There’s no reason to feel guilty about applying display: inline to create a horizontal menu from an unordered list. You’re not changing the semantic content of the list (it’s a navigation list, after all), you’re just changing its presentation.

It seems like I remember reading somewhere that the whole point of cascading style sheets was to separate content from presentation. Now, where would I have seen that?

Oh yeah. Everywhere.

Reasonably Graceful Degradation for Older Browsers

Don’t try this in Internet Explorer 7; you’ll only break your heart. Internet Explorer 7 and Internet Explorer 6 don’t support the display: table property, so the page renders… badly. Don’t believe me? try it for yourself. Go ahead, I’ll wait.

The good news is that we can fall back on the (admittedly) imperfect float/clear method for Internet Explorer 6 and Internet Explorer 7 by adding the following conditional statement:

<!--[if lt IE 8]>
  <link rel="stylesheet" type="text/css" href="3c_float.css" />
<![endif]-->

Be sure to add this after the primary style sheet declaration so that the style rules in 3c_float.css take precedence. And you should really avoid having any in-page style rules. (But if you’re this far along into cascading style sheets, you’ve probably already learned that lesson.)

3c_float.css needs to contain replacement styles only for those that use the display: table and display: table-cell properties. If you want to save some time, use the style rules from the first cascading style sheet example above. We’ve already tested them, after all.

So, for not very much effort (certainly less than getting floating columns to work), you can have perfect multi-column pages in Internet Explorer 8. And when your site is viewed in Internet Explorer 6 or Internet Explorer 7 (or Internet Explorer 8 in forced compatibility mode), it will render using the old tried-and-true faux-column display using float and clear.

Tags: development, web, web standards

This entry was posted on Tuesday, May 26th, 2009 at 3:45 pm and is filed under Expression Studio, Expression Web. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.