We'll the author says intent was to prove it is possible. I believe him.

> We'll the author says intent was to prove it is possible.

Which is a straw man - nobody's arguing that it's impossible. The argument generally centers around valid, web-tested, academic-approved CSS layouts being practical for use in the real world. I worked with someone who did freelance web design on the side and who said "I program for Opera and only test in Opera." Does anyone really need to wonder why he didn't have any repeat business?

I also worked in a slicing sweatshop, and using CSS to do layouts instead of tables tripled the amount of time it took to slice a PSD mockup. Department-wide adoption of the YUI CSS framework brought this down to maybe double, although YUI still has some of the basic layout issues that CSS itself does (eg the lead engineer on YUI CSS told me himself that the only way they know of to solve the equal-height column issue with YUI is using Javascript, and there is no equal-height column CSS hack that's anywhere near to understand or cross-browser compatible as table-tr-td-td-td). The greatest time sinkhole by FAR was CSS layout debugging. It was not infrequent to have someone's whole day go down the drain struggling with some god-awful cross-browser issue that would be relatively easy using tables for layout. So I've been there, to the point where I know that the only CSS books that aren't nearly completely worthless are _CSS Mastery_, _Bulletproof Web Design_, and maybe O'Reilly's Definitive Guide.

Doing a layout in perfect, valid CSS separating presentation from content (as much as possible, because I've never seen them successfully completely separated in a non-trivial project) is sort of like writing a book and having a sticker on the cover that says "This book has been validated 100% grammatically correct." Swell, but it really doesn't have anything to do with the price of spinach.

Just like how the fact that many people have a beef with using CSS for layouts doesn't negate the fact that for everything else it eliminates redundancies and is generally the cat's pajamas, the fact that tables look ugly doesn't negate the fact that in many cases they Just Work faster and are easier to understand than CSS for standard layouts like three equal-height columns.

Dude! I have spent ages in debugging IE shit as much as you have. And have lost much of my hair! But I dont think what everybody's discussing here is cross browser compatibility. When you start with CSS you know are very much aware that some browsers dont support it. Each and every tutorial, all those books, point it out. So why go back and complain CSS sucks.

My condolences - I too know the pain of IE debugging. But it seems you're making the same error that the linked article is. The relevant question is not "is it theoretically possible to do layouts in CSS?", it is "CSS-based layouts vs. table-based layouts: which is better for Just Getting Shit Done in the Real World?"

And in my experience, for reasonable client-acceptable cross-browser compatibility (ie IE6/IE7/FF/Safari), CSS based layouts often cause more headaches than they're worth.

No. In my experience a mix of CSS and table based layouts work out fine. There are cases when floats and clears are overkill. But so is a complete table based layout.

> No.

I appreciate your enthusiasm, but I'm sorry to say your assertive "No" doesn't negate the fact that my experience is that CSS-based layouts are very often not cost-effective compared to table-based.

We had 15 people doing slicing all day, every day, 50-60+ hours a week. We weren't all morons. You better believe we figured out what works and what doesn't, and as I said, the switch to CSS-based layouts tripled the time it took to get a site to a client. If you want to believe that everyone in the shop just happened to simultaneously become mentally retarded at the exact time the switch was made, you're free to do so. Personally, I think Occam's razor suggests otherwise.

I respect your experience. And I dont want to drag this. If CSS hasnt worked out for you, and you are using tables, its fine. Nobody's saying that its wrong.

The point is, choose whats best for you. For me CSS has worked!

>The point is, choose whats best for you.

Agreed 100%.

> The argument generally centers around valid, web-tested, academic-approved CSS layouts being practical for use in the real world.

Your argument, perhaps, but that's not what the post was about.

> Your argument, perhaps, but that's not what the post was about.

But while your post was correct, it was a straw man - nobody makes the argument that it's impossible to do a markup-order-independent, three-column layout in CSS, especially when you only have to make it work in Firefox 3 on Linux and don't have to deal with equal-height column issues.

The argument that apparently half of HN is discussing now is "which is more pragmatically effective for client-acceptable layout: CSS or tables?" The post doesn't address this, because a layout that's only been tested in Firefox 3 for Linux would be completely unacceptable to any client I've ever done business with.

> nobody makes the argument that it's impossible to do a markup-order-independent, three-column layout in CSS

The first post I quoted did exactly that. The OP argued that if you changed the order of a 3-column layout, it 'destroys' the presentation. Both my first and amended examples proved this wrong.

I work in web development. I specialise in PHP but I do front-end work on a day to day basis. I too struggle with the frustrations that half-arsed browsers such as IE present. Please do not assume that because I chose the side of CSS on this occasion to demonstrate its capabilities, that I do not 'get' what the css vs. table / developing for IE arguments are about.

> The first post I quoted did exactly that.

Not exactly; he took a "canonical" example of such a layout from an authority on the matter and showed that even with such an idealized example from such an ideal source, changing the order of the content breaks the output.

Also, your counterexample uses different CSS for the "in order" and "out of order" proofs-of-concept, which defeats the purpose - the point is that the CSS needs to stay exactly the same with the presentation not changing upon changes in markup order.

> Please do not assume that because I chose the side of CSS on this occasion to demonstrate its capabilities, that I do not 'get' what the css vs. table / developing for IE arguments are about.

I never said you didn't get it. I said you didn't address the relevant argument in your article. Your article is correct and well thought-out, but it doesn't address the argument that is dividing the HN community, pitting brother against brother.

> Also, your counterexample uses different CSS for the "in order" and "out of order" proofs-of-concept, which defeats the purpose - the point is that the CSS needs to stay exactly the same with the presentation not changing upon changes in markup order.

I already addressed that; see the new URLs in a comment above.

Her.

oops. my bad.

Don't worry, you're not the only one that made that assumption. Apparently only men should be allowed near code ;)

"He" can mean male, but in English it's also the gender neutral.

BTW you have 4 w's in the url in your profile on HN.

Thanks for the heads up.

:). It was just a careless mistake. And we really love it when someone can figure out CSS better than us ;).