It is correct that some layouts are easier created using tables rather than CSS. However, there is also many types of layouts which cannot be created with tables, but require CSS.
A serious article (rather than a rant) would explain the limitations of both approaches, given the limitations of current browsers.
Separating layout and content for purity's sake doesn't make sense, because the ordering of the divs in the html affects the layout. If you want to separate content and presentation, use XML and XSL. That should cure any ambitions along those lines. HTML is a presentation language, not a content definition language.
I was on the tables side, but some of the new grid layout CSS things like Blueprint are almost as easy. However, Blueprint makes it easy by putting the presentation back into the HTML page- you don't have semantic markup, you have styles that define the height and width of your element. So, it gives us the simplest thing (mixed content and presentation) but in a way that looks like it complies with the "no tables for layout" dictum sent down from CSS heaven.
I don't understand why people keep trumpeting this like it's a big revelation. The layout of everything depends on the order whether you use CSS or not. Floats were not intended to change this, and complaining that they don't just because tables do is apples to oranges.
If you look at the specs, the example use case for floats is floating an image element inside a paragraph. For that and many other cases, floats work exactly as intended and expected. It's only when you use floats to emulate a table-based layout without using display:table that a problem like this comes up.
Because the dependency on entry order makes the div's class semantically meaningless. Yes, the order in tables makes a difference, but in a table, that makes sense. With CSS, however, if I add a div with a class name like "center_column", then I expect to be able to put it anywhere in its enclosing context, and it should render in the center of that context.
CSS as an abstraction leaks, and it leaks blood. It seems that CSS-supporting designers (on this thread and elsewhere) accept this far more readily than hackers. A table is a table is a table: you expect its order to matter, so no one blinks when this turns out to be the case. CSS looks superficially like it provides a higher level of abstraction, but it (1) does not, and (2) requires considerably more effort to get right.
<div class="article">
<div class="author">
John Q. Public
</div>
<div class="text">
Some text goes here.
</div>
<div class="date">
February 3rd, 2009
</div>
</div>
As I said before, floats do not change that (from the CSS2 spec): In the float model, a box is first laid out according to the normal flow, then taken out of the flow and shifted to the left or right as far as possible. Content may flow along the side of a float.
What you're asking is to be able to modify the document tree, which modifies the normal flow, and then have something which explicitly depends on the rendering of the normal flow to not change.
But I dont really see your point in favor of tables, since CSS is strictly more powerful in this case.
At least people aren't using JS to move everything around on the page any more. That really sucked.
But now that the pendumlum seem to have swung from never use tables for layout to always use tables for layout, I suppose it should be extended with an explanation of when not to use tables :-)
http://news.ycombinator.com/item?id=464342
http://www.newmediacampaigns.com/page/why-css-should-be-used...