I spent much time researching why the tables are bad camp exists, and this is the result of my research:
The beginning
Initially tables were the only way to layout a web page, and so much abuse occured - this was before CSS and the only way to make a layout was to use 'spacer' gifs. spacer gifs were one pixel gifs that you had to put in td elements so they would retain there shape. As you can imagine this was a mess.
Then came CSS and the DIV tag, many books were written about 'spacer gifs were evil' use Divs and CSS, and this was correct spacer gifs were a nightmare.
However what seems to have happened is the baby was thrown out with the bathwater. Tables are the easiest way to do what's now called 'liquid layout'. You can do these using Div's but it takes a bit of fiddling, and the result can sometimes be wrong if the screen width becomes too small.
From a software development point of view I regard using div's for liquid layout as an optimisation - semantically what you want is a spaced layout that resizes dynamically. However, using tables does cause a couple of problems that div's avoid (which I mention below), div's avoid these problems but at a cost (which I also mention below).
The real crunch was early on - Netscape 4.7 (the one that was widely used) crashed with multiple nested tables (try this on browsershots if you're curious). So Div's were used and techniques for using div's in browsers became prevalent.
The combination of the Netscape problems and spacer gifs created the 'tables are bad' thing and new developers coming in were told 'tables are bad' and it continues.
So people used div's and IE6 became the dominant browser, but the engineers who built IE6 never expected anyone to use divs for layout - that's what tables were for - and so the mess occured with div's and css and IE6. This, I think, made the situation worse, as to use div's meant you could MS bash, it also required a deeper understanding of HTML and CSS and so arose the specialist web designers who used multiple incantations in DIV tags and CSS to create what any joe could do in 5 minutes using table tags. This strengthened the DIV/CSS camp until anyone who used table tags was openly scorned as a newb.
In any argument you have with the DIV people the last one they always bring up when they're on the ropes is that braille readers can't handle tables - because the ordering isn't defined. However most of these people don't actually write for disabled readers and this too seems to be without base, I have asked many times for concrete examples, and never have received any.
There are some negatives with tables:
1) The whole page needs to be loaded before it can be rendered (in some cases), as the layout can't be done until the contents of each cell are known.
2) This seems to be a big one - it's very hard to edit nested tables in notepad and figure out where you are, you need more expensive tools to navigate the document, something web developers seem to be averse to for some reason. Me, I buy whatever tools make my life easier.
The negatives with Div's as layout are there too:
1) If you have a few fixed width div's with the rightmost floating (the usual way) and make the page smaller than the width of the div's the rightmost falls below the other div's, it's not possible to stop this from happening. If you use tables a scroll bar appears.
2) You have to have a deep understanding of CSS and a lot of time to experiment on multiple browsers to see what works
Div's can start to display quicker as they have a fixed width usually and so no layout algorithm is required to be calculated. (The actual time to calculate the layout is no longer an issue, but it used to be for tables).
So that's the issues as I see them, and how we ended up with these two camps. If anyone has some more data I'd like to see it. Personally I use a couple of layers of nested tables to establish the rows and columns and fill it up with div's as necessary, and don't worry too much any more. Oh and use styles to actually describe the TABLE/TR and TD elements, which is CSS as far as I can see.
For point 1) on Div negatives: you could set a min-width on 'body' or the host container if it's flexible to ensure the width never gets small enough for the divs to clear.
The beginning
Initially tables were the only way to layout a web page, and so much abuse occured - this was before CSS and the only way to make a layout was to use 'spacer' gifs. spacer gifs were one pixel gifs that you had to put in td elements so they would retain there shape. As you can imagine this was a mess.
Then came CSS and the DIV tag, many books were written about 'spacer gifs were evil' use Divs and CSS, and this was correct spacer gifs were a nightmare.
However what seems to have happened is the baby was thrown out with the bathwater. Tables are the easiest way to do what's now called 'liquid layout'. You can do these using Div's but it takes a bit of fiddling, and the result can sometimes be wrong if the screen width becomes too small.
From a software development point of view I regard using div's for liquid layout as an optimisation - semantically what you want is a spaced layout that resizes dynamically. However, using tables does cause a couple of problems that div's avoid (which I mention below), div's avoid these problems but at a cost (which I also mention below).
The real crunch was early on - Netscape 4.7 (the one that was widely used) crashed with multiple nested tables (try this on browsershots if you're curious). So Div's were used and techniques for using div's in browsers became prevalent.
The combination of the Netscape problems and spacer gifs created the 'tables are bad' thing and new developers coming in were told 'tables are bad' and it continues.
So people used div's and IE6 became the dominant browser, but the engineers who built IE6 never expected anyone to use divs for layout - that's what tables were for - and so the mess occured with div's and css and IE6. This, I think, made the situation worse, as to use div's meant you could MS bash, it also required a deeper understanding of HTML and CSS and so arose the specialist web designers who used multiple incantations in DIV tags and CSS to create what any joe could do in 5 minutes using table tags. This strengthened the DIV/CSS camp until anyone who used table tags was openly scorned as a newb.
In any argument you have with the DIV people the last one they always bring up when they're on the ropes is that braille readers can't handle tables - because the ordering isn't defined. However most of these people don't actually write for disabled readers and this too seems to be without base, I have asked many times for concrete examples, and never have received any.
There are some negatives with tables:
1) The whole page needs to be loaded before it can be rendered (in some cases), as the layout can't be done until the contents of each cell are known.
2) This seems to be a big one - it's very hard to edit nested tables in notepad and figure out where you are, you need more expensive tools to navigate the document, something web developers seem to be averse to for some reason. Me, I buy whatever tools make my life easier.
The negatives with Div's as layout are there too:
1) If you have a few fixed width div's with the rightmost floating (the usual way) and make the page smaller than the width of the div's the rightmost falls below the other div's, it's not possible to stop this from happening. If you use tables a scroll bar appears.
2) You have to have a deep understanding of CSS and a lot of time to experiment on multiple browsers to see what works
Div's can start to display quicker as they have a fixed width usually and so no layout algorithm is required to be calculated. (The actual time to calculate the layout is no longer an issue, but it used to be for tables).
So that's the issues as I see them, and how we ended up with these two camps. If anyone has some more data I'd like to see it. Personally I use a couple of layers of nested tables to establish the rows and columns and fill it up with div's as necessary, and don't worry too much any more. Oh and use styles to actually describe the TABLE/TR and TD elements, which is CSS as far as I can see.