Last time I talked about CSS on this blog, I got a lot of feedback, and let me tell you, I'm all about the attention, so I thought I'd give my take on the CSS vs. tables debate.
I've read a lot of excellent articles on the subject (here's one that comes out in favor of tables, and here's one that comes out in favor of CSS). Most of these articles are written from the perspective of a developer who is solely responsible for all of the markup and CSS (if applicable) on a site. For the past six months or so, I've been part of a large team where development and design are done by different people, and code is usually not maintained by the person who wrote it. So I have a new perspective on a lot of issues, and this is one of them.
First, I think that the debate is often framed in the wrong way. People who are in favor of tables often assume that the "pro CSS" people are advocating the complete elimination of the table. I'm not convinced that this is what they're saying. For instance, one argument I read refuting the claim that CSS sites download faster than table-based sites is clearly talking about tables that are not graphic heavy.
However, if you look at a website that is simply an image produced in PhotoShop and sliced in ImageReady, you can see that many, if not most, of those images could be replaced by things like background colors or small, repeated background images. If you already have a fairly good foundation in how those work, you will use those CSS or not. But often these "CSS is better" articles are aimed at people producing sliced image sites, not people who already know how to produce light table-based sites. Sometimes these articles might take things a bit too far, but I think that it's on the same principle as going to France as an exchange student. Sometimes you need to stop speaking English for a while if you want to truly learn to speak French, and I think sometimes you need to pretend that you never learned tables so that you can expose yourself to parts of CSS you might not learn if you allow yourself to fall back on tables while learning.
But none of that's really specific to team development, so I digress...
One thing that I haven't seen discussed much, though it's alluded to in the CSS zen garden project, is that sometimes you need to take exactly the same code and make it look completely different, layout and all. In the Zen garden, this is an exercise just for the sake of doing it, but this requirement does come up in actual projects. Let me tell you, folks, it's just not possible to move something from the left side of a table to the right using the same markup, or to make something 100 pixels tall in some cases and 200 pixels in other cases (ok, that last you could do using javascript, but that's a discussion for another day).
A more subtle form of this type of situation is where you have to copy a code snippet from one page into another page. It can be difficult to impossible to reuse the three middle columns out of a table, and even if you can do it, you're going to spend unnecessary amounts of time cleaning up the code after you're done. By contrast, the company I work for has a lot of nearly identical sites that just have different styling. Usually these come to me without meaningful names and ID's on the form fields, but because our pages are well-formed, I can copy and paste an existing form (with ASP code embedded) from one to another and have the site up and functioning in minutes.
One place tables really fall down is troubleshooting when things go wrong. I've inherited code before where the original developer copied and pasted bits and pieces from different nested tables, some parts of which were in different files (via includes), and there were warnings all over the place from Dreamweaver about close tags without open tags and vice versa. It's not fun searching through nested tables to find which <td> tag got closed twice! Yes, it can be a pain when div tags get mismatched, but at least there are fewer "moving parts" to a div.
On the down side, most developers have taken a learning path that teaches them that table-based layout is easier than CSS-based layout. I think that many of us forget how much hair we ripped out learning to do layout with tables, but the simple fact is that, when you're working in a team of developers of unknown skill sets, you can usually be pretty sure they'll understand table-based layouts. So sometimes it makes sense to use the table-based layout because someone else might need to come behind you and edit it who doesn't have a good grasp of CSS.
There's also the time consideration: if you're not confident in CSS, it might take you much longer to get it right than the equivalent table-based layout. Ultimately, that balances out and CSS becomes more intuitive and faster, but sometimes the needs of now are more important than some nebulous future benefit.
My personal opinion is that you shouldn't be stuck using tables because that's all you know, and you shouldn't rigidly limit yourself to CSS because you think you "should." Picasso was a great painter because he learned the rules of classical painting first, then learned how to break them effectively. By the same token, I think that developers should know all of their tools well so that they can choose the best blend for the situation that confronts them.