Shindig Blog - Yeah I Use Tables For Layout, So Sue Me

"Hi, my name's Andrew Burke, and I, ... I use tables for layout."
"Hi Andrew. It's okay, we love you."
"I'm not alone? I though I was alone!"

(apologies to Bill Hicks)

This is a rant I've been wanting to make for a while - it has been in draft and private emails for a few months - but now similar rants are finally coming to light and getting attention - so I'm adding my voice to the slowly growing chorus.

I use tables for layout. Not in a stupid way, but because CSS just doesn't do what I want to do. And I'm in good company

I think it's interesting that these public confessions to using tables are coming out at the same time as details about the next generation in CSS layout, which looks like it will act a lot like regular HTML tables, but done 'properly' in CSS.

Anyhow, onto my own rant:

I use CSS for all sorts of things, including a lot of layout. It's great - and certainly a massive improvement over how styling and (most) layout was done before (I remember the FONT attribute). However, I think there's a conspiracy of silence about using tables for layout. I believe that a lot of people are unsatisfied with using CSS for layout, but figure that it's because they just don't know enough - so saying they have problems with it is like admitting they're not 1337. Well, I'm getting old enough to start being a cranky iconoclast, so I've decided to just get this off of my chest.

I started building websites back in 1994, in the early months of Netscape. I spent a lot of time back then arguing with people (especially people with traditional design or desktop publishing backgrounds) that these were web pages and not flat paper. You actually wanted to avoid absolute positioning, since screens and windows and devices can be any size and you want to support a wide range of readers. Embrace the flexibility and join the world of New Media!

But if you really wanted to do absolute positioning - and you shouldn't have wanted to, but clients can be demanding - there were ways to do it, but they were awkward messy hacks that involved invisible GIFs with arbitrary widths and heights, and meticulously arranged tables with clever fixed widths and colspans. IIt seems to me that the people who designed CSS spent too much time listening to the paper-based graphic designers, and they spent a lot of energy 'solving' the precise layout problem, with fixed widths and absolute positioning. I think that they missed the whole point of the web, which should be flexible and dynamic. Even worse, in designing CSS to support absolute positioning and fixed dimensions, they actually made it harder to do dynamic layouts.

I remember how disappointed I was the first time I checked the source for a mind-blowing CSS Zen Garden design and discovered that it was mostly just absolute-positioned elements over graphics - and worse, that if I grew or shrank the font in my browser it would either not resize the text, or the layout would completely fall apart. It wouldn't adjust to fit my browser window either.

A few years ago, I went 'back to school,' searched all the best websites, and read through the Head First XHTML and CSS book to see what the latest word was in HTML and layout. I felt like there must be some obvious layout technique that I was clearly missing, and once I found it I'd be able to leave this messy table crap behind and become 'pure'. The book indeed had several chapters explaining all of the different ways to get multicolumn layouts to work - but each one finished with "this is great until someone shrinks the window and then everything overlaps" or "this unfortunately doesn't work in IE". Many sites promised the secret to 'forms without tables', but just floated elements next to each other and assigned them fixed widths - fine for "Age: " and "City: " but not so good for "Validated Item Code: "

The main advantage of tables is that they enforce the relationships between elements rather than their size or position. When you don't know the size of a browser window, the amount of content within a layout element, or how a user might override things like font sizes, it's very important to be able to guarantee that certain things are always next to or above each other.

The other advantage with tables is that they stretch and shrink more intelligently than CSS does. You can set up fixed or percentage widths on individual elements, and the remaining elements with expand or shrink to fill the extra space.

If you want to position and size your elements absolutely, then go ahead and use CSS. If you're using tables for absolute positioning, then I agree that you're doing it wrong (1996 is calling and they want their "Trainspotting" soundtrack back). But if you're doing real work on the web, and not just pretty brochureware, I would argue that you don't want to use absolute positioning.

I build business applications, so my pages are more like templates for dynamic content than pristine fixed layouts. Sometimes an element will contain a small piece of text, and sometimes the same element will contain a massive 30-column spreadsheet-style report, possibly with graphics somewhere in it too. Fixed-width CSS layouts don't work in this context, and dynamic width CSS tends to fall apart badly. Elements overlap, or fall off the screen, or hop to the 'next line' and blow everything out of relation.

There was a time a few years ago when you could expect windows to be around 800 x 600, and most sites out there are set up with absolute layouts with fixed widths of 640, or 800, or 1024, or whatever - but those days have passed. My time is split between a 30" monitor at home, the 12" screen on my trusty old ThinkPad X30, the regular 15" screen on my MacBook Pro, and whatever-it-is on my iPhone - and things are going to get more varied, rather than less (consider the tiny screens on the popular new Netbooks). I can't tell you how many sites suddenly have no margins and require constant left-right scrolling to read on the ThinkPad's 12" screen, or have a thin strip of content in between oceans of margin on my 30" desk monitor.

The standard argument against tables is that "your HTML should focus on the content, leaving the CSS for style and positioning information. What about all those blind people?!" Well, your CSS site probably doesn't work very well for blind people either. Do you use AJAX? Do you manipulate the DOM at all? Do you use Flash?

In fact, having a layout that doesn't fall apart if the user grows the font size to maximum would probably do more for people with poor eyesight than 'proper' CSS would.

Also, CSS isn't as pure a separation of style and content as it pretends: the order of elements on a page still matters quite a bit, for example. Furthermore, if you've done any of the fancier DHTML effects with JavaScript, you'll notice that you still need to put the dimensions and positions directly into the element's STYLE attributes, thus breaking that separation of content and layout.

When the new CSS spec comes out and everyone is using a browser that supports it, I'll happily leave tables behind as a layout strategy forever. However, I can't wait until 2015, so until then, I'm using tables to get things done.

So, yeah, I use tables for layout. In fact, look at this page right here. Go ahead, change the size of your browser window, or change the font size. Notice how the logo is locked in place, while the rest of the header stretches and shrinks to fill your window, while keeping the gradient pattern always aligned to the left? Notice how this text also expands and shrinks so it always fills the available space, but still keeps proper margins and spacing? Notice how the footer also stretches and shrinks as well, so it always completely crosses the bottom? That's done with a relatively simple table for the major layout elements, and some clever CSS styles for repeating backgrounds.

By the way, if you shrink your browser window on this page to a very small size, you'll notice that the sidebar to the right ends up underneath the blog post text. That's because I decided to use 'float: right' for it. I guess nobody's perfect, eh?

---

Category: Technical

Previous: The Different Kinds of Done Jan 24, 2009 16:11

Next: Careerious - Ruby and Rails vs. C#/.NET Feb 09, 2009 15:46