In 2001, Jeffrey Zeldman, then leader of the Web Standards Project, published a groundbreaking article on the A List Apart site: To Hell With Bad Browsers. This manifesto was to change the face of the Web for many of us authoring sites at the time. Zeldman wrote:

The burden of moving the Web forward had shifted away from browser makers and onto browser users and web designers. For progress to be made, users would have to upgrade to newer browsers and designers would have to begin using the features of those new browsers.

To encourage this direction, WaSP launched the Browser Upgrade Campaign, shown in Figure 4.1, at the same time that Zeldman’s manifesto was published. The campaign advocated using one of two methods to let users know they should upgrade their browsers. The “gentle” method involved displaying your page without style information for users of old browsers such as Netscape 4, adding a suggestion at the top of the page that users consider upgrading their browsers. The alternate method was to actually block users of old browsers from accessing the site, redirecting them to a browser upgrade message—either on your own site or on the WaSP web site.

Figure 4.1. Redirection page for the Browser Upgrade Campaign

Like many other designers and developers at the time, I responded by publishing my own site with a CSS layout and valid markup in April 2001.

With the imminent release of Internet Explorer 8, we find ourselves in the very same position as we did back in 2001. The time for lobbying the browser makers to improve their support for web standards is over—for now, they have done their part. Now it’s our turn.

As I write this, efforts such as Save the Developers are already gearing up to encourage users of IE6 and IE7 to upgrade their browsers. Building that awareness is one part of the equation. The other is to give users a reason to upgrade, by using the features only available in up-to-date browsers in our designs—CSS tables, for instance.

As in 2001, we have several ways we can approach this process of gentle persuasion, and the most appropriate option will vary from project to project. Obviously, if we wanted to make the biggest impact possible, we could simply block old, out-of-date browsers from viewing our sites. That’s a rather extreme approach, though, and not one you are likely to be able to justify, even on your own personal site—or not for another couple of years, at least.

No, most likely you’ll want to let users of older browsers view some version of your site; the question is, what version should you allow them to see? What are your options?

For Internet Explorer 6 and 7 to display a simplified layout, we need to provide them with some different styling information. One option is to use conditional comments.

Conditional comments were introduced by Microsoft in order to give web developers a way to target versions of Internet Explorer. While I have some misgivings about the insertion of code for the browser within comments—which are supposed to be ignored by the browser—they do provide a simple way to pass information that will be ignored by other browsers and non-targeted versions of Internet Explorer.

For example, if we want to include a style sheet for only Internet Explorer 6—a situation that is my most common use of conditional comments—we use the following markup:

<!--[if IE 6]>
<link rel="stylesheet" type="text/css" href="ie6.css" />
<![endif]-->

We’d typically put this style sheet after the main style sheet in the document, then overwrite any problematic CSS with rules for IE6 only in this special style sheet. The cascade approach dictates that if two style sheets in the document have the same selectors, the one that comes later in the document will be applied after the rules in the earlier style sheet, and will have the last word on how elements are displayed.

In this case, we want to add a style sheet for any version of Internet Explorer below IE8, so we use this conditional comment in which lt IE8 means if less than IE8:

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

This condition is ideal, as when Internet Explorer 9 comes out we can safely assume it won’t have dropped support for CSS tables. Therefore, this condition will still work—and it won’t accidentally catch a newer browser than was available at the time of building the site. This block of code goes in the head of the document, after the original style sheet, as shown in Figure 4.4.

Figure 4.4. The head of my document with the conditional comments in place

We create the new style sheet by saving the existing style sheet with a new name: 3col-csstable.oldbrowsers.css. The selectors in the existing style sheet provide a useful starting point for our IE6 and 7 style sheet.

Now, we don’t need to preserve every selector in this style sheet; many of the existing rules for styling text and simple aspects of the layout will work just fine in older browsers—we only need to override the rules for the elements that are set to display as tables, table rows, or table cells. So we can delete everything in the new style sheet other than those rules, which leaves the following CSS:

#main {
  display: table;
  border-collapse: collapse;
}
#main .inner {
  display: table-row;
}
#nav {
  display: table-cell;
  width: 180px;
  background-color: #e7dbcd;
}
#extras {
  display: table-cell;
  padding-left: 10px;
  border-right: 1px dotted #d7ad7b;
  width: 180px;
}
#content {
  display: table-cell;
  width: 380px;
  padding-left: 10px;
}

Then, we merely edit these rules to make the changes needed for Internet Explorer versions less than version 8. The first step is to empty the #main and #main .inner rules:

#main {
}
#main .inner {
}

We’ll leave these selectors in place as a reminder, in case we need to come back and apply styles to the entire content area of the page. We don’t need them to create our table and table row for now, though, so we can leave them as unstyled blocks (the default for divs).

Now, since we don’t have a CSS table, we need to decide how we’ll lay out the div elements nav, extras, and content. Each of these are CSS table cells in our table-based layout, but what do we do with them in our simplified layout?

Back in the section called “The Grid’s the Thing” in Chapter 1, I explained that CSS was originally designed with the idea that every page would be a vertical stack of blocks. If we embrace this assumption in our simplified design, we should find the CSS code required to describe it very easy to write. Let’s remove the display property values for each of these elements—they’ll default to display: block—and set their width property back to auto so they span the full width of the page:

#nav {
  width: auto;
}
#extras {
  width: auto;
  border-right: none;
  border-bottom: 1px dotted #d7ad7b;
}
#content {
  width: auto;
}

Since we’re stacking the blocks vertically instead of horizontally, we’ve also moved the dotted border from the right side of the extras div to the bottom side. Figure 4.5 shows what the layout looks like in IE7 at this point.

Figure 4.5. The simplified layout so far

The page is now a vertical stack of blocks, but the contents of those blocks still look as though they were designed to stack horizontally across the page. Let’s add a few extra rules to our simplified layout style sheet to correct this issue.

It we look at the navigation menu, which in up-to-date browsers runs vertically down the left side, we can see that displaying it as a vertical list really doesn’t work in this layout. It would be nice to stack those menu items horizontally across the page in our simplified layout, but again, we run into the problem that CSS wasn’t designed to perform horizontal stacking of blocks.

We could fall back on our bag of tricks and use floats to perform the horizontal stacking, but remember that it’s this kind of fragile hack we’re trying to avoid with a simplified layout. Luckily, there is a much simpler option: display the list items as inline elements, so they flow across the page naturally—no stacking required!

#nav {
  width: auto;
  padding: 8px 0;
}
…
#nav li, #nav a:link, #nav a:visited {
  display: inline;
}

As the main style sheet has both the list items and the links within them displayed as blocks, we need to set display: inline on the list items, as well as both visited and unvisited links inside them. With a little extra padding on the nav div, we can even make the thick border below each of the links fit nicely inside our simplified layout.

The other aspect of the design that really isn’t working in this simplified layout is the padding around the news items in extras. We can fix this easily with a final style rule:

#extras .box {
  padding: 0;
}

And we’re done! Our completed, simplified layout is shown in Figure 4.6, as displayed by Internet Explorer 7.

Figure 4.6. A simplified layout that looks decent in IE7, without resorting to CSS hackery

For years, we’ve criticized Microsoft for holding back the Web by abandoning development of Internet Explorer while its competitors responded to our demands and added the new CSS features. With Internet Explorer 8, Microsoft has caught up. All the features we need to improve the Web with solid, reliable, and—most importantly—easy-to-learn page layout techniques are now available across all the major browsers.

If we don’t start using those features now, then who’s holding back the Web? The users who haven’t upgraded their browsers? Until we build sites that take advantage of the new features added to the latest browsers, how can we expect those users to upgrade?

When we told Microsoft we needed it to improve Internet Explorer, we were making a bargain with the software giant: “You improve the browser to make our lives easier, and we’ll build the sites that take full advantage of it, giving your users a reason to upgrade.” Microsoft has done its part; now it’s our turn.

Yes, embracing new CSS techniques while supporting older browsers involves some extra work, but this is something we’ve done before, and the Web benefited greatly. Back in 2001, web designers began to abandon HTML tables used for layout in favour of then-nascent CSS layout techniques, which were made possible by improvements in the newest browsers, including Internet Explorer 5.5. At the time, there were still plenty of Netscape 4 users around, and designers were forced to create separate versions of their sites for these users.

The designers of 2001 didn’t have the benefit of conditional comments to ease this extra burden, but one by one they made the bold move to CSS layout. The result is that the vast majority of sites designed today use CSS layout, and benefit from the advantages it provides.

With the release of Internet Explorer 8, it’s 2001 all over again.

If we want to benefit from advances in browser support, at some point we have to decide that some browsers have limitations which mean they can’t benefit from the full look and feel of the design we need to implement. That doesn’t mean cutting those users off from being able to visit and use your site; it’s just that the design isn’t going to look the same for those users.

As an example, let’s revisit the image gallery grid we developed in the section called “Making a Perfect Grid” in Chapter 2, shown here in Figure 4.11.

Figure 4.11. The grid using display: table;

Remember how well CSS tables work here, as we can make all the boxes in each row the same height, regardless of how much text is entered. To support Internet Explorer 7, we can add a couple of rules to float the boxes instead of using the table grid:

.row {
  clear: both;
}
.image {
  float: left;
  margin: 2px;
}

The issue here will be that the backgrounds aren’t as neat, but it degrades quite well, as you can see in Figure 4.12.

Figure 4.12. IE7 with the floated version of the grid

There really isn’t a good way to emulate this type of layout without CSS tables. This grid effect is something that has been elusive until the advent of CSS tables, which is why you often see sites with captions spilling over the edges of boxes when the browser’s text size is increased. The developer has assumed everyone has their text set to the same size, and fixed the height of the boxes to create this effect.

Floated and positioned CSS layout techniques have their problems, which can mean quite a bit of testing in different browsers—even in up-to-date browsers. The stability and reliability of table-based layouts was, for a long time, the main reason some designers chose to stick with HTML tables for layout, rather than embracing newer CSS techniques.

Using CSS tables for your layout will bring this stability to your CSS layout work. You’ll waste a lot less time fixing mysterious bugs and inexplicable behavior in even the latest browsers.

If you’re also able to use Option 1 (no fallback layout) or Option 2 (simplified fallback layout) described above, your testing burden will be reduced in browsers that don’t support CSS tables as well. But even if you must resort to Option 3, fixing squirrelly layout bugs only in IE6 and 7 sure beats fixing bugs across the full range of browsers in use today!

I’m sure that I’m not the only designer working with CSS every day who experiences frustration over implementing my complex, grid-based layouts using current CSS that works across browsers.

As grid-based layout has made its transition from traditional media and onto the Web, often the only ways to implement these layouts using CSS are to add additional markup or to use a complicated mixture of CSS floats and positioning; neither of these were intended to create the kind of rich, visual interfaces that the modern Web demands.

While the (slow) work of the CSS working group includes new layout tools, these are some years away from becoming available. The table-related values for the CSS display property go some way to making my life happy, and as they’re being implemented in the next version of Internet Explorer, they should make those other frustrated designers happier too.

—Andy Clarke