I was speaking to a site designer starting out the other day, and she asked me the question every newbie wonders; what’s really so wrong with using tables for design?

Anyone with a basic understanding of accessibility and a degradable web browsing experience just shuddered. But I’m pretty sure there’s a few people sat there wondering what actually is so wrong, and this article is for you.

It is true that I’m still learning about everything there is to know on the subject, but the fact is that when a 17-year-old college student can look at websites and feel a certain sense of being appalled — and quite mainstream websites too — you really wonder what the hell is wrong with some developers. Just a little bit of research explains the cascade of reasons to develop accessible and semantic work.

The main pro tables arguments are:

1. You can make a site layout look just as good using tables as you can using CSS stylesheets.
2. It’s often faster to build a site layout with tables than CSS for inexperienced designers thanks to tools like Dreamweaver.

The second point is probably why you will find still a few big corporation websites resorting to table-based layouts, and yet smaller sites (like this one) are using semantic HTML and CSS. As for point one, it’s true. You can find some beautifully designed websites that are built using tables for the layout, and the Media Temple site at http://www.mediatemple.net is a good example.

So why are tables so evil then? Well, the thing is; designing a website using a tables is like designing a kettle that looks great, but only from one angle and you can only pick it up using your left little finger. In addition, it’s powered by the owner sticking a dripping wet hand against a plug socket and attaching this thing called a ‘kettle clamp’ to their tongue. My point is; you’re horribly hindering your users by not designing it properly.

Code that looks like this:

Makes a million times more sense than this:

In addition to having a hell of a lot more possibilities. It’s also incredibly light, I mean, just look at the two. The second version is a mess (I’m a fan of the term ‘tag soup’), whereas the first one is readable even by someone who doesn’t understand HTML. Collaborating with others and figuring out where you were when you last worked on something a couple weeks ago becomes a hell of a lot more simple when you’re not being a stubborn table monkey.

It’s also interesting to load up a tables-based site on a mobile phone*, and then doing the same thing with a semantic website. Try www.mediatemple.net using your phone’s web browser, and then www.notorange.co.uk. Which one is actually readable? Which one loaded faster?

Besides, once you get the hang of CSS — especially using emerging solutions like the Blueprint framework — you’ll find it a breeze and wonder why you ever abused the tabular data function in HTML. That’s exactly the point you see; tables are for tabular data. For spreadsheets, invoices, and other things you can dream up along the lines, and not for making your logo line up with your strapline, and your content only be 500px wide. CSS can do all of that and so much more, and all it takes is the update of that single file and the entire site is affected. No more page by page editing.

You brought yourself into the 21st century yet? I sure hope so. Good luck with learning CSS, and I’m more than happy to help you if you need it.

___________

Richard Henry is a graphics, website and print designer living in the UK.

The article appeared originally at http://www.notorange.co.uk/.
Reprinted with the author's permission.