The whole reason the movement away from tables began is because complex layouts (nested tables) do not render correctly in different browsers and it does not separate style from content like CSS does.

Tables also makes it harder for crawlers/interpreters to understand the page as content may not be hierarchically correct due to layout issues, etc.

If you use tables, you don't have to avoid CSS. They compliment each other. I agree that nested tables are ugly, but they're also completely necessary now because of CSS. Using tables to render your main multi-column layout wouldn't require any nesting. Also, tables are more likely to render in different browsers (including mobile browsers) than a complex CSS layout.

Given the number of CSS hacks and extra HTML tags in exactly the right order that is necessary for most column layouts the end result is almost always less complex with a table.

Tables should really be used for data that requires it e.g. number sets etc., and not for layout.

True, using tables for layout in some sites is much simpler than CSS but people who do that usually do so today because they do not know how to do it in CSS properly.

Either way, all is fine, until they start using tables within said layouts (e.g. for number sets or even more mutli-columning in subsections) and things start to get problematic. This is especially evident when they try to use the content in various sites or try to change formatting for cross-browser related issues (often best solved by having base style sheets for various browsers).

Just my experience and thoughts, ultimately use whatever is best for you, and you are comfortable with :)

IE and FF handle column widths in tables rather differently, which can cause some problems with table based layouts. I've been round this circle recently and ended up back with a 'pure' CSS approach

When did everyone forgot that HTML is presentation markup? It's object code. The content is back at the ranch in a database.

| ...and it does not separate style from content...

I often hear this mantra, but why is it really important?

I think it's a good goal, but not to the extent that a designer is spending a ton of extra hours working on a layout simply to try to ensure this perfect separation of style from content.

...well you may as well ask why MVC (or MVP or similar) is important.

They all share the base reasons, which is the seperation of concerns, which ultimately leads to systems/solutions being easier to develop/maintain/extend/change.

I suppose I should clarify. I didn't mean to imply that content-vs-presentation was unimportant; I think it is important. I meant to ask, is it always important enough to justify all the extra cost associated with it?

It's presented as this cardinal rule: the web designer shalt not mix layout and content, nor shall the designer obfuscate thy code with any table, less it is presented in the form of a database view. (+1 for dramatic license.)

And I would be all for that, IF the development platform that we were all forced to use actually supported that in a helpful way.

But, it doesn't. Give me a little time, and I'm pretty sure I can come up with at least one presentational trick that is absolutely, positively impossible with cross-browser CSS -- and I'll even allow you to use all the CSS hacks you can come up with. But, the very same presentational effect is a piece of cake with a single HTML table.

MVC, or MVP, are sound ideas ... where they're made practical by the development environment. However, it's possible to write perfectly easy-to-maintain code for a business without strictly following those models, and if you're dealing with some framework or development environment that makes the MVC model difficult, then I think it's foolhardy not to make some practical considerations in lieu of this stainless ideal.

EDIT: I just remembered the CSS layout that I wanted so badly and never could figure out. It drove me nuts, but this was a couple of years ago and somebody might have figured it out since. All I wanted was two columns; first was completely liquid, the second was liquid with a minimum width; auto scroll bars (but not displayed unless necessary); and -- the part I couldn't get to work -- a single line border drawn between the two. For some reason, no matter what I tried, introducing that line border caused one browser or another to add scrollbars, or draw it short, or something else idiotic. Three days of Googling, CSS hackery, and other nonsense later, and I wrote a table in just about a minute that did the job fine.

Where I work, we separate layout and content quite religiously because they're done by different people. A mess of table based HTML may make things easier for the layout guy, but it makes it more difficult for the content people to work with later on.

For example, let's say the HTML guy makes a page where product data should go. What exactly that product data is, he does not know when he's making the page. It doesn't matter, he can just make the HTML and fill it up with some Lorum Ipsum text. Then when it's time to put the actual product data in, this will take ten minutes at most for the content people to do if the HTML is clean and minimalist, while it will take a few hours if it's nested tables or worse (Dreamweaver generated crap or somesuch).

In the end, the cost of having someone do HTML properly, meaning using HTML for content only and dealing with presentation in CSS, which the content people will never see, offsets the costs of having developers wade through messy HTML every time they need to change something.

Tables would make that not work so well on, say, an iPhone. The way it currently works, the "content" column is going to be the first thing visible when the browser's not wide enough to fit all three.

Tables render better on mobile browser than pure CSS layouts. Mobile browsers are very smart about tables and almost always do the right thing. CSS is just too complex to get a good result when you need to scale down to a small screen.

...sometimes. When you put three cells next to each other in a table, you're telling the user agent "this is a row of related data". It's difficult to intelligently choose how to lay those out if there's not space for them to appear side by side.

That CSS layout leaves a bit more up to the user agent. The primary content appears first, if there's not space to position each column next to the primary content, it drops down below.

Mobile Safari handles CSS based layouts just fine.

have fun styling those tables for your clients without images

You can apply all the standard styles to tables you do realise.

Look at the css, and it's just all a bit ugly with the work arounds for browsers.. A little hacky.

Also what if you want 4 columns? or maybe you want one of them a fixed width...

Sure, with the next version of css, tables will be eaiser to do with just css, but now it still seems like a hack to me.