steve kwan user experience designer

<div> vs. <table> (Part 1/2)

(June 17th, 2006 - 1:01AM)

A recent conversation with Richard sparked my interest in writing this article. He was asking my opinion on whether it was okay to build a site layout using tables instead of <div>s. Here are my thoughts. But first, a bit of background.

How websites have evolved

In the beginning, Tim Berners-Lee created the World Wide Web, and the people filled it with textual content, and He saw that it was good. In many ways, I miss the good old days when you could go to any website - even websites for big companies - and get black text on a gray background. Easily readable, even by your grandmother.

But then the Web got pretty. People realized that Web pages can be more than just documents of text. HTML allows you to embed tables in your pages, and with a bit of Web wizardry you can use said tables to break a page into sections. A page could be a table with two columns: the leftmost column is your content, and the rightmost column is your navigation. How cool!

Before long, designers were using tables to make pretty, professional websites. No longer was the Web just a repository for documents. We owe a lot to the <table> innovation, because this allowed us to look at the World Wide Web from a more aesthetic viewpoint. Unfortunately, structuring a website with tables has some problems.

First and foremost, it's unnatural. Tables are meant to store rows and columns of data, not to format document layout. Building a website out of tables is like designing graphics using Microsoft Excel. The tool isn't right for the job.

Second, very rarely is a webpage built with a single, simple table. Table-based pages are often constructed from a whole orgy of tables nested inside each other. This results in an inflexible design and a maintenance nightmare. Below is a screenshot of the Eloquent Systems Inc. website with the tables and cells outlined. (It's interesting to note that this site was designed in late 2005, and still employs the dated tables technique; this is a good illustration of how prevalent this technique has become.)

Third, table-based pages have major accessibility problems. Blind users, for example, use computer speech readers to browse the Web. They don't surf the Web visually like most of us; rather, they experience it in audial form. When pages are broken down into tons of rows and cells for purely visual purposes, speech readers get confused and often can't recite the content as it was meant to be presented. This is a good example of how table-based sites violate a very important design principle: always separate data from presentation. Which leads us to the <div> technique.

<div> and Cascading Style Sheets

With the advent of Cascading Style Sheets (CSS), we gained the ability to completely separate presentation from data in our HTML. This gave us a lot more flexibility. You could now replace your website's stylesheet and give the user a completely different experience. For examples, see my alternate styles at the top of this page.

When making extensive use of CSS, you no longer need to use tables for presentation. You can replace that orgy of tables with a slightly less crowded orgy of <div> elements instead. (Note: Although you can use pretty much any element, <div> has become a de facto standard for this method.)

Despite being available for many years, the <div> method still hasn't been entirely adopted. This is unfortunate, but not entirely surprising. It turns out that it's a lot harder to build a website using only <div>s than using tables. A whole myriad of problems occur when you replace the reliable rigidity of tables with the flexibility of <div>s. I'll discuss that more in part 2.

What you've read so far may be mostly review if you're familiar with Web development. If that's the case, you're probably snickering to yourself because Steve is posting common knowledge that's been known for years on his site. Snicker away, you bastard. I'll try to make part 2 more inventive.

This article is continued as <div> vs. <table> (Part 2/2).