Here's the deal: CSS was designed to have all the styling and layout power of presentational HTML, and more. Even universally hated features like "blink" were supported, so nobody would have to use presenational HTML ever again.
So what whent wrong with tables? The culprit is that the CSS equivalent of tables, the display:table CSS property (defined in CSS 2) has not been implemented in Internet Explorer yet, even though the standard is 12 years old (IE8 will reportedly support it, though).
So there is no direct CSS equivalent to the layout properties of tables which works in IE. You can emulate some of the properties using floats, absolute positioning and so on, but be aware that this approach is not the "correct" CSS way. Rather it is a workaround around limitations in IE's implementation of CSS. Using tables for layout is a alternative workaround for the same problem. The approaches have different tradeoffs.
The main tradeoff is that HTML-tables are bad for accessibility, while CSS alternatives are often convoluted and hard to maintain. So the choice is basically if you want to cause pain for yourself or for disabled people. Its not hard to understand how this debate turns into more of a moral than a technical discussion.
Note that it is not all uses of tables which require workarounds to implement in table-less CSS. Before CSS, tables were used for a wide array of layout tasks like spacing, margins, positioning and so on, which is generally better handled by CSS today. The limitations are specifically when tables are used as dynamically adjusting grids. I wrote a small article to point out the concrete issues: http://olav.dk/articles/tables.html
BTW - it's a myth that tables render the same across browsers. Table rendering has about the same amount of inconsistencies and browser differences as CSS. The difference is that there is no "right way" to render tables, since table rendering is not specified anywhere. It's all just a chain of reverse-engeneering leading back to the first haphazard table implemtation in Netscape 1.1. With CSS there is at least a spec, and the hope that browsers implentations move incrementally closer to the spec.
So what whent wrong with tables? The culprit is that the CSS equivalent of tables, the display:table CSS property (defined in CSS 2) has not been implemented in Internet Explorer yet, even though the standard is 12 years old (IE8 will reportedly support it, though).
So there is no direct CSS equivalent to the layout properties of tables which works in IE. You can emulate some of the properties using floats, absolute positioning and so on, but be aware that this approach is not the "correct" CSS way. Rather it is a workaround around limitations in IE's implementation of CSS. Using tables for layout is a alternative workaround for the same problem. The approaches have different tradeoffs.
The main tradeoff is that HTML-tables are bad for accessibility, while CSS alternatives are often convoluted and hard to maintain. So the choice is basically if you want to cause pain for yourself or for disabled people. Its not hard to understand how this debate turns into more of a moral than a technical discussion.
Note that it is not all uses of tables which require workarounds to implement in table-less CSS. Before CSS, tables were used for a wide array of layout tasks like spacing, margins, positioning and so on, which is generally better handled by CSS today. The limitations are specifically when tables are used as dynamically adjusting grids. I wrote a small article to point out the concrete issues: http://olav.dk/articles/tables.html
BTW - it's a myth that tables render the same across browsers. Table rendering has about the same amount of inconsistencies and browser differences as CSS. The difference is that there is no "right way" to render tables, since table rendering is not specified anywhere. It's all just a chain of reverse-engeneering leading back to the first haphazard table implemtation in Netscape 1.1. With CSS there is at least a spec, and the hope that browsers implentations move incrementally closer to the spec.