Tables for Layout: A Love Letter

Before Flexbox, before CSS Grid, before even reliable CSS float support, there were tables. And they were good enough.

I know, I know. Using tables for layout is semantically incorrect. Screen readers get confused. It's mixing presentation with content. Every web standards blog from 2003 to 2010 told us this was wrong.

But let me tell you something: tables worked.

The Reliability Factor

In an era when CSS support varied wildly between browsers, tables provided something invaluable: predictable behavior. You could create a three-column layout with a table and know, with certainty, that it would look the same in Netscape Navigator 4, Internet Explorer 5, and whatever other browser your visitors were using.

Try saying that about CSS in 2002.

The Technique

The classic table layout looked something like this:

<table width="100%" cellpadding="0" cellspacing="0">
  <tr>
    <td width="200">Sidebar</td>
    <td>Main Content</td>
    <td width="200">Right Sidebar</td>
  </tr>
</table>

That's it. Three columns. No floats to clear. No z-index issues. No collapsing margins. No mysterious gaps. It just worked.

The Spacer GIF

The real artistry came with the spacer GIF — a transparent 1x1 pixel image that you'd stretch to control spacing. Need 20 pixels of padding? Insert a spacer GIF with width="20" and height="1".

Was it elegant? No. Did it produce pixel-perfect layouts across every browser? Yes.

Moving On

We were right to move away from table layouts. CSS-based layout is more accessible, more maintainable, and more flexible. But I sometimes miss the certainty of tables. You nested your <td> elements, and things went where you told them to go.

In a world of justify-content: space-between mysteries and align-items: center that doesn't seem to center anything, there's something to be said for a good old-fashioned <table>.