Skip to: Navigation | Content | Sidebar | Footer

Weblog Entry

Gasp! Tables!

May 13, 2004

Andy Budd, a name some of you will recognize as a proponent of CSS-based design, has decided to take a long, hard objective look at the arguments made in favor of CSS.

I’m sure we’ve all found ourselves writing fairly complicated CSS to do something that would be trivial using tables. Take form styling for example. It’s possible to lay out even very tricky forms using tables in just a few minutes. You can achieve similar results by floating elements with CSS, but it’s a lot more involved

The rest of Andy’s points are lucid, level-headed, and enforce something that you may or may not personally believe: CSS-based design under all circumstances, while a goal to strive for, is hard. Using a table for layout may at times be the best way to get the job done.

For example, it’s (relatively) easy to keep a CSS-based design functioning on a simple 10 page, custom-designed site; you’re designing for rigid and known conditions. There’s almost never a need to fall back to tables under those circumstances.

But it’s a whole new level to keep a large 500 page CMS-driven site functioning, which could potentially see large images dropped in the content area (thus breaking your floats), or multiple hands involved in creating markup (including those that are markup-illiterate), or any number of other conditions beyond your direct control. More and more of us are learning this from direct experience, myself included. Just because you know how to code without a table in sight doesn’t mean the rest of the stakeholders in your project will.

None of this is permission to go wild. One simple table stripped of presentational markup should almost always suffice in these circumstances. And please, leave the multiple nested tables in 1999.

But claiming structural tables are wrong under any and all circumstances is too much of an ideal at this moment in time. The practical reality of today’s web is that learning curves and browser support can sometimes raise the bar too high for full-out CSS design in certain scenarios. A designer using proper discretion who pays special attention to accessibility, essentially a designer who is educated and capable of using tables well, may consider the layout table a still-valuable tool.

Reactions will be mixed. Vive la difference!

Update: The thinking behind this post has been expanded on and clarified here.

Reader Comments

web says:
May 13, 01h

There is a big difference being a savvy-developer and being a zealot. Last time I checked, tables still validated.

You need to pick and choose your battles. Especially when dealing with client projects. Spending 3 days of client/company money fixing an 3px IE bug is just plain unacceptable.

With that being said I still avoid tables like the plague, but sometimes a little population control is a good thing.

Tom says:
May 13, 01h

I couldn’t agree more. Like I always say, we can’t be “standards lemmings” and follow these recommendations over a cliff when common sense should prevail.


May 13, 01h

Well said. You’ve got to be balanced and know arguments for and against using tables. As long as you do, you’ll be okay.

Daryl says:
May 13, 02h

I’ve had great success using a blended approach to build Web apps. Using CSS to lay out the structure of your app with a combination of absolutely- and relatively-positioned divs keeps presentation manageable, while placing form elements within divs is often best done using tables. I’ve achieved some pretty cool Windowsy application layout effects using this technique. So I agree.

May 13, 02h

It’s also great when your fancy CSS-driven layout (and overall code purity) is broken by some off-the-shelf Java-based WYSIWYG HTML editor.

“font” is bad, “FONT” is worse.

Andrew says:
May 13, 02h

I think, as far as possible, we should obviously be leaving structural tables in the last century. But yes, as web said, “spending 3 days of client/company money fixing an 3px IE bug is just plain unacceptable”. If it’s impractical to avoid tables, then use them.

It may be semantically wrong (or whatever the latest buzz phrase is in that area), but it still works. There comes a point where we just have to get on with it, and use whatever works best for the job in hand.

Hans says:
May 13, 02h

I have to admit that I’ve once considered submitting to tables for my comment form, but I resisted and spent a whole day making a decent-looking form.

I shall always say that tables are evil. Big, fat, ugly, and evil.

May 13, 02h

yup, i’m struggling with this issue at work at the moment…although i’m fairly confident in getting all of the main to be table-free and css driven, many of our web authors who sit in the faculties, schools and support services know just enough to use DW 4’s WYSIWYG. some have been doing “web stuff” for the last 6 years or so. getting these people to learn the ins and outs of css-driven layouts is proving quite challenging…but i’m slowly getting there. in the meantime, i don’t have a fit if they use tables…but if it’s something simple to replicate via css, i take the time to explain to them why it should be done the “new” way, and show them how easy it is to implement.

Jay Small says:
May 13, 02h

In the newsletter I just sent out last night – see – which explains my travails trying to get a folder-tab-style interface to work, I had to confess to using a table to ensure a desired effect.

Dave, thanks for making me feel a little better about it!

May 13, 02h

I try to use CSS when I can, but when it comes to forms, I almost use tables. It can even be argued that forms are tabular data, which is often the case. This comment box could be considered tabular data quite easily, it’s just that I’m editing the data in the table.

May 13, 03h

CSS is great, but when IE rears it’s ugly head, what are you supposed to do? Sure, on personal projects it’s no big deal to fight and fuss, but on anything with a budget why kill yourself? When the broswers are finally on an equal playing field, then maybe it will be time to shun tables, but until then set the tables free!

Eric says:
May 13, 03h

That was my thought when reading this initially - forms are tabular data. They have multiple fields, like a spreadsheet. I don’t see a problem using tables for this at all.

That said, I still will think they are evil for presentation. But I haven’t come across something yet that I can’t do with CSS, and I think that knowing it inside and out is the place to start. I’m still an idealist. If we know the new paradigm, we can design sites that don’t try to do things CSS can’t do.

That said, I haven’t done work on large sites where problems would come up, so I’m sure in time my naivete will fade :)

Ireney Berezniak says:
May 13, 03h

Personally, having been slowly moving to CSS-based layouts, mostly personal pages, I noticed that I am often forced to employ numerous hacks, or seek alternative solutions to accomplish something that would have taken me relatively short amount of time to get done via tables. Maybe it is a learning curve thing … once I learn the ins and outs, the box model, and other, hacks, I can probably develop the same UI in as much time.

However, I can certainly understand how CSS layouts could be discouraging to web developers, and affecting the rate of it’s adoption. We’ve learned hacks to get our table layouts to work nicely in all browsers, now we need to learn hacks to get our CSS layouts to play nicely … not exactly the promised land we’ve been lead to believe.

Of course, this is not all a fault of CSS … browsers are to blame for the most part. But, hey … maybe by 2010 we’ll have 100% compliance from all browsers, and no bugs to work around …

Now, that’s the promised land … if only we had a Moses to lead us there …


krf says:
May 13, 04h

I’m not sure I’d say it’s “easy” to implement unless you’re dealing with one browser, but it sure makes maintenance easier and doing things stucturally will help you and your team down the road when you have to go back to that code and figure out what you built.

The last site I built for a client was all xhtml/css, but like it was mentioned, it’s a relatively small site and relatively straightforward to code.

Sites at work driven by CMS and other tools have to be carefully designed and constructed in a manner that may not always work 100% without a blighty table. Slowly but surely, we’ll get there. Once that happens, I’m sure someone or some company will change the rules again - standards be damned.

Lach says:
May 13, 06h

I think a lot of the problems that you encounter using CSS, are first time only problems. For instance, I had problems doing my first float based layout a while ago, because I’d always used positioining before that. Now though, if I want to do a similar feat I can do it in half the time.

Or take for instance form markup. Most forms use a fairly standard layout, which means since I’ve already mastered the layout of forms once [ ] (although there’s more I’ve done since then that isn’t covered there), it’s a simple matter of writing the correct form markup, and a quick CSS copy & paste, with maybe a few alterations if necessary for the site.

I guess what I’m saying is, if you don’t have the time, then you might need to go with tables, but if you can afford to spend the time, you should, since it means in future you’ve got that problem sorted if you come across it again.

Luke Redpath says:
May 13, 07h

The other david s > “It can even be argued that forms are tabular data”

Sorry to deviate slightly, but I still don’t understand this argument. The clue is in the quote. Forms are NOT data, therefore they aren’t tabular DATA either. They are in interface for inputting data, but not data themselves.

Creating a form like this:

label | field
label | field
label | field
label | field

It might LOOK tabular in APPEARANCE, but this is purely presentational, as you may well want to layou your form out like this instead:



Therefore I must refute any claims of forms being tabular data.

Going back to the original discussion, yes, if you are in the process of learning CSS - of course, its an ongoing process - but if you are at the foot of the learning curve then tables may well be the better option at that point.

> “spending 3 days of client/company money fixing an 3px IE bug is just plain unacceptable”

I realise this is an exaggerated example, but if you do find yourself spending that long on a CSS bug, then it could be argued that your knowledge of CSS isn’t quite advanced enough to be using it in actual client work.

I think its down to making that decision…”am I good enough with CSS to start using it in my client’s projects yet?”. If you can answer yes to that, then it is time to leave behind tables for good (with the only excpetion being for when you need to get your site looking the same in Netscape 4.x or some suitably ancient browser…but thats for another discussion).

Jim says:
May 13, 07h

Whether forms can be considered tabular data or not, it certainly does make sense to utilize tables in some instances, at least until all browsers are css 3.0 compliant, at which time we can all quit hacking and start designing again.

Tables are not evil, they just do not make sense for layout purposes, not now that css positioning is the standard. Tables are always a good idea for data columns, of course - and you can use css to make them attractive.

It’s a no brainer really.

May 13, 08h

It puzzles me why CSS people are so anti-table. I understand that <table> tags don’t belong in the markup, because it’s presentational. But that doesn’t mean that tables are bad, only that CSS needs to support tables so we can move it out of the html. Once we have CSS3 and display:table (like in 10 or 20 years), then pure CSS layouts will be practical in all cases.

J. King says:
May 13, 09h

> Once we have CSS3 and display:table (like in 10 or 20 years), then pure CSS layouts will be practical in all cases.

Let me rephrase that for you:
“Once we have CSS2 in Internet Explorer instead of “CSS1.5”, then structural layouts that do not compromise for visual style will be practical in all cases, instead of just for users of everything except Internet Explorer.”

May 13, 09h

Right tool for the job. Thats what it comes down to for me. If a table will do the job (IE tabular data and some forms) then that is the right choice. but nesting several dozen tables into each page is not the right decision.

Using a sledge-hammer to “nudge” something into place is not good regardless of your profession.

May 13, 09h

A little too quick with the Post button.

That should be ie as in the Latin “id est” for “that is” not IE .

David Robarts says:
May 13, 11h

This sounds a lot like ALA’s “No-Fault” CSS again.

May 13, 11h

I’ve just finished re-designing a student data analysis tool, its a huge site which is dynamically generated with hundreds of pages.

It’s been tough to convert it into css 2 and xhtml 1.1, the original coder didnt really know what was going on… but the journey has been a good one, and I’ve had some pleasing results.

I know exactly where your coming from when you say

“Just because you know how to code without a table in sight doesn’t mean the rest of the stakeholders in your project will”

But thankfully i’ve been pushing hard, and i’m on the way to converting all of the designers ( and a large majority of coders! ) to standard compliant work.


May 14, 02h

After reading all this, especially the part about “But it’s a whole new level to keep a large 500 page CMS-driven site functioning,…” it got me scared a bit. I just finished a template design for a gaming website, totally in CSS/XHTML with almost no table. Now it’s in the hands of the developers and soon it will be tested. So far things seems to go well… but I kind of hold my breath after reading this. Hopefully things will end up fine. One thing that gives me hope is the fact that the developers are all for the idea of using CSS layouts. So I’m probably worried for nothing ;-)

And secondly I now understand when I look at my blogs stats why my CSS form is so popular ;-) I made it just as an experiment but yes, it was a “pain in b*d” and I’m not sure if I would actually use it. There are always browsers where it doesn’t look 100% correct.

This article is very enlightening, I’ve always wondered now that I started to use CSS can I never use tables now? I think indeed you can still use tables. One thing I would NEVER do is use nested ones.

May 14, 03h

There’s no disgrace in hybrid layouts built around a simple table.

Current limitations in CSS columnar formatting have resulted in some highly creative thinking and examples of clever workarounds – but I will always advocate a pragmatic approach to development.

A few month’s back, Dave Shea fired my imagination with CSS and I was hell-bent on developing table-less sites but after countless hours of fiddling, fudging and fruitless frustration it dawned on me I was square-pegging a round hole; multi-columnar formatting is better achieved using a simple table wrapping my logical block markup.

I am now at peace.

Luke Redpath says:
May 14, 03h

Hmm, I find it concerning that after all the work people have done over the past year to spread the message of standards that so many people are still saying “its ok to use tables” simply because its easier. If you care about standards, then I don’t think this is at all the right attitude. Nobody is expecting people to become a CSS whizz overnight, but IF you have the time to learn to use it to its full potential (I understand not everybody has that time) then I see absolutely no reason to go back to using tables because its “easier”.

Why are people still not getting it? More and more big sites are converting to CSS-based layouts - look at, look at, look at cnet, look at wired etc. If these big players can do it, then anybody can. I think its time to stop making excuses for table-based layouts.

Yes there are certain things that are easier to do with tables. Yes, hybrid table/css layouts are useful if you are only just starting to learn CSS, do not have the time or means (client restrictions?) or need to support legacy browsers, but if the option is there, IMO there is only one choice. Otherwise you are just going backwards.

Perhaps some people will choose to see me as a CSS “zealot” - I don’t know why, I have no say in what you choose to do, however for the purpose of discussion I’m willing to stand up and say that its time to stop excusing table-based layouts.

May 14, 03h

I found myself thinking this just the other day - I spent several hours trying to get an daily event calendar to look alright using floated divs and headings only to decide that a table for that sort of data would be perfectly acceptable. I think in this case the table actually cut down on the code by a little bit, and it certainly required less CSS rules to look the same.

Luke Redpath says:
May 14, 04h

I don’t think anybody is suggesting tables shouldn’t be used for genuine tabular data, such as a calendar. To not would be as incorrect as using tables for layout.

May 14, 07h

Like many people earlier comments I can only agree with those that have advocated the common sense approach, it’s simply not always possible to take into account every variable that the final site will be exposed to.

And then there is the time issue, it’s obviously not viable a lot of the time to spend days rearranging complex pages with CSS when you could do the same with a perfectly validating well built, well thought out table in hours.

CSS is great, it gives amazing flexibility, but at the moment it is time consuming to build universally good CSS on every platform and there are times when going back to certain HTML entities makes solid time and business sense.

dusoft says:
May 14, 08h

I can only agree with you Dave. I’ve been coding comply with valid XHTML 1.0 Strict code and later found that tables are necessary for the layout. It was quite difficult to fight all float bugs when making it 3-column CSS layout, also it has not been good for SEO. I have found it difficult to find solutions to some bug that occured and I guess that had to do with floats widely used. Nevertheless, I changed for basic TABLE layout with 3 columns defining <table id=”xxx”> and <tr id=’yyy’> when needed. That’s just plain markup with CSS on top. We can use it, that’s not so bad. Otherwise <div>’s are used.

Brian G says:
May 14, 09h

I work for, and we have about a dozen people here who work on the site on a daily basis. Unfortunately, this site has always been seen as a SPORTS website (emphasis on Sports, little emphasis on website), and as a result, the milage of the HTML education of the staff varies greatly. I only finally managed to convince them to close and ‘s a few years ago. Moving them to CSS based design is going to be nigh impossible.

If it was just me (like it is with my side projects), I’d say, “BOOYEAH CSS and Standards all the way”, but it’s not, and there’s no way I’ll be able to teach these old dogs all of the new CSS tricks when it’s easier for them to rely on the “old ways” to get the job done.

It may not be right, but it’s the hand of cards I was dealt with.

Tom T says:
May 14, 10h

Hmmm…where to begin…most of what I do are specialized web apps, i.e. primarily form-based, so my view on tables is in general much different than the usual one here.

That being said, it’s nice to see you (Dave S, not the other Dave S) mention that “by the way, sometimes using a table is OK”. I regularly use tables to lay out forms; partially because the “general” audience (those used to filling out paper forms, for example, or still working with *gasp* mainframe apps) find it easier to use and grasp.

So my approach in the last three years has been to use a table (sometimes with one level of nesting) primarily as a grid tool, and to use CSS to define the elements within the grid.

Personally, I see nothing wrong with using tables to do layout. Whether you call it “table” or “grid” makes no practical difference, and we all know that a grid layout is not evil in other mediums.

Part of the big issue I see here is the blurry line between “document” and “application”, which has plagued the world ever since server-side app authoring as been accessible (no pun intended). Even some of the other technologies (*cough* XAML *cough*) suffer from this potentially confusing paradigm. The fact is that a markup document is a document; it is a captured state at a particular moment.

An application by it’s very nature represents a number of different states, any of which may be captured using a document. So IMHO, a lot of the argument about “tables being presentational” is grounded in the wrong paradigm to begin with.

Of course tables are not structural. If its document semantics that you are interested (primarily as a vehicle for content communication), then CSS is inherently more powerful than locking presentation within structure. But if it’s complex interaction, then I feel that the total separation of presentation and content, while laudable, is almost a waste of time.

(bear in mind I feel that a decent application structure will operate on a document “in flux”; that data document *should* be semantic and only semantic).

Rijk says:
May 14, 12h

The problem with allowing tables for layout: how to stop people from going wild with them, and dropping all semanticly interesting elements like H1 and lists etc. As a tool for creating a flexible grid, they are of course much faster to use.

Justin says:
May 15, 04h

Amen. When you already have 80,000 documents (in Lotus Notes *cringe*), some with horrible layouts and huge images. It’s much safer to use a table based layout, because after all, the most important thing is that it’s usable. A sensible table layout isn’t _that_ bad in the first place.

May 15, 05h

On tables in forms…

Didn’t Mark Newhouse already muse on this (on A List Apart and his own site?) Based on code by Eric Meyer.


Basically, it isn”t that much harder than using tables for forms!

Alan Spear says:
May 15, 09h

You could always clip large images. In fact you should always limit the dimensions in which your clients can add content. But yes, using tables is a hell of a lot easier in some cases.

Tom T says:
May 15, 10h

(In response to Luke Redpath)

I’m sorry, but the last time I looked at the specs, tables *were* still part of the standard. The argument here isn’t really about standards, it’s about separating content from presentation…i.e. semantic documents.

The point I was trying to make, which you seemed to ignore, is that there are situations where you are not dealing with a document paradigm anymore (in order words, full-fledged web-based applications) but an application paradigm.

Sure, I use tables to lay out most of my forms. That’s because its still a standard, and it does what I need it to do. It’s not like we’re using IE specific tags (thank god MARQUEE has not appeared more than it has). We’re still using standards. It may not be the spirit of what the w3c put forward, but it’s still part of the spec.

I think you have to remember that there’s more than one way to skin a cat here, even when using the standards. Sure, if you are dealing with a hyperlinked set of documents (your standard web site), then absolutely, do it with pure CSS. Lots of space saving, easier to control, etc. (I do use CSS pretty much exclusively when doing pure web sites, with the exception of some experiments…and that has less to do with the desire to use tables for layout and more to do with the poor implementation in some browsers).

But to ignore part of the standard because it doesn’t conform with some idealized version of the “accepted” use of the standard, that I have a problem with.

May 16, 09h

I have recently tried to stick with CSS-based layouts with my designs, and while I have had a lot of success, it’s frustrating to deal with IE 6!! Like it was said above, you can’t spend too much time fixing a bug like that when you can solve it with tables and move on to the next project.

So my motto now is to try and get it to work with CSS, but if something comes up and I get stumped, I add a table here or there, (only a few ;) )and then I get the project done. The client won’t understand that I was trying to get a float to display properly in 1 browser… and as long as you don’t go crazy with tables, it shouldn’t make too much of a difference on file size, or time to display the page on the site, it will still conform to XHTML.

That’s how I deal with CSS and table-based designs.

May 16, 12h

For the forms discussion:
I am surprised that no one mentioned fieldset, with label and legend, that’s about all the markup you need for creating usable forms.

As for the 500 page cms discussion:
Accepting that a CMS gives you poor output, is accepting the choice of a poor CMS. You should be able to control most aspects of the output from a CMS, as it’s primary function must be managing content and not publishing content.
Storing content as structured documents, free of the current favourite flavour of presentation, allows you to control the output, and eventually to change it easily for major redesigns.
Think XML + XSLT, then go look for you CMS monster.

jim says:
May 17, 06h

There is no Black or White, there are only shades of Grey…

If I hand-craft the layout and have total control of the content - my client can have a pure css solution. at a cost ;)

If they want the budget option and/or editorial control - as is usually the case - then one of my trained monkeys gets a copy of dreamweaver and the client gets a css/table hybrid =)

David Hayes says:
May 17, 07h

I am primarily a server-side programmer, and one of my main responsibilities when working on a project is to tie site designs with dynamic content from databases. In the past the site designs handed to me have all been table based, making it easy for for me to intigrate things like shopping cart contents int othe design.

But recently the designers I work with have started moving to CSS based layouts. I found it to be very time consuming to give dynamic content the same functionality without tables. It was possible, but not woth the effort. I have since decided to go for a hybrid approach; Using tables only when the data I was retreiving, required a tabular display. This method has worked great; the designers can still use css and I can fit my data grids in there div’s without much extra work, keeping the layout intact. The end result is a standards compliant, dynamic site, developed in efficient manner, meating deadlines, and giving our clients more bang for there buck.

I think tables should still be used, but only for information that demands a tabular display, with rows and columns.

Just my two cents.

May 17, 12h

Remarkable how many results turn up on a web search for “tyranny of standards.” Shelley Powers’ O’Reilly article ( ) memorably called the WaSP a lynch mob.

May 17, 12h

I must say that as someone that develops sites to hand off to others, sites that must be edited in WYSIWYG browsers, and web applications, I couldn’t agree more with Dave. When you are a professional, it’s all about practicality.

Someone said eariler that CSS is beta, which isn’t exactly true. Yes, it is a spec, but it is in its infancy. It isn’t the ultimate or only presentational language solution and has a long way to go, both as far as the spec and implementation are concerned.

Taking my work as an example, I’m putting together a site with 2- and 3-column layouts. I comped them up nicely in pure-CSS with my dummy latin content. Everything looks great, and it is working nicely across browsers. The problem is, I now have to run it through a slew of tests to try and see how easy it is to break. If it doesn’t break (which isn’t likely, especially in IE) then I have to make sure it works with Dreamweaver MX. That presents another problem, because this site is going to be handed off and worked on in the WYSIWYG editor and must look correct in Dreamweaver and not break when adding content there.

Moral of the story is, I already know where this is going. I’m going to break it and it’s going to look shoddy in Dreamweaver and I’m going to have to revert to a simple table layout to ensure my columns look proper. Then again, I know many more CSS-hacks this time around, so I’ll probably spend more time trying to fix it and make it work. Who knows, maybe this time I’ll be successful.

(Not sure where I went with that story, but I can’t understand how any professional dev wouldn’t agree with Dave on this one.)

May 18, 08h

The main problem with tables is that it really locks the site design into a 3 column layout, (or whatever they’ve been used for), which means that is it’s decided that the site would look better with no columns, 2 columns, or even 4 colums or any other style you can think of, it would mean that you would need to alter the structure of the document just to change the layout.

Also, tables (especially 3 or 4 column layouts) can’t really be optimised for incremental loading. Say for example you have a really large list for your navigation menu up the top, followed by the left column, then the centre column, and finally the right column. It might take quite a long time to actually get the main content in the middle that the user is really interested in, not to mention the dynamic resizing as each column is downloaded and rendered, which is really annoying.

Using CSS, it’s not difficult to get a presentaiton like that using structured layout, optimised for incremental rendering using a structure like this:

<div id=”content”
<div id=”section1”/> (column 2)
<div id=”section2”/> (column 1)
<div id=”section3”/> (column 3)
<div id=”sitenav”/>

This way the main content is delivered first, ending with the site navigation, since it will usually be the last place your visitors look before leaving the page.

Dominik H. says:
May 24, 03h

So true. Iam ‘forced’ to use a CMS which doesn’t care about valid output.

It’s really hard to see that my codes breakes because the developers didn’t spend a minute on thinking about valid code :(

I beeing one of the lead developers of a famous bulletin board software often come on trouble because i really need tables but i nearly forgot how to use them because iam not used to it anymore :D