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.

I disagree. Conceptually, it is exactly how you would do layout in the old days. This still works, btw, it's just considered bad practice.

It's a bit like saying that a kitchen knife is totally unlike a dagger and completely unrelated in every way, because the former is for slicing food and the latter for stabbing.

You seem to be misinterpreting my arguments -- I'll assume not deliberately. They could have easily provided the same facilities for backwards compatibility of table behavior while also providing clearly-named and usable methods for doing things as basic as centering.

Is your position that CSS is a thoughtfully, well-designed system for presentation, and that the complaints of 95% of professionals web developers are the result of their own misunderstanding of it? Can you imagine taking such a position on user complaints as the CTO of a private software company?

Yes I mis-formuled it.

>It was IEs failure to implement it for nearly a decade that meant nobody was aware of or could use it for many years.

No it wasn't only IE, display table was also broken in Firefox and Opera. There were plenty of layout that you couldn't obtain in CSS but worked well with HTML tables.

I think this is the core misunderstanding in this discussion. CSS 2 supported both text-flow and tabular layout and both layout models were reverse-ingeneered from how Netscape rendered HTML.

There is this weird idea that CSS is somehow opposed to tables or tabular layout, while a significant part of CSS2 is actually the codification of how tables render.

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.

I cannot. They no longer exist. This was 14 years ago. I left web development shortly afterwards.

For your example, horizontal alignment was easy. One container div with a width of 99.9% and a left/right margin of auto. Inside you place three divs (columns) with a width of 33.3% and float left. Add another div at the end to clear the float.

Vertical alignment required a "hack."

http://www.greywyvern.com/code/min-height-hack

And to be clear, I never called it "elegant." I simply suggested it was possible.

Should CSS have been better? Sure. But, by that measure, it still sucks today.

That's exactly what I said. I think the difference is in our interpretation of that causality: you see it as an intentional concession in the name of backwards compatibility; I see it as a failure of imagination.

That's quite a misunderstanding of the past. Your proposition is only technically correct: CSS1 (Dec 1996) did not have table display properties, but they were added in CSS2 (Mar 1998). They were available early enough to matter.

The reason why many Web authors did not design with these properties is not the fault of the W3C, but rather because of the typical Microsoft sabotage. In the early 2000s, I personally did not give a shit about IE - my standard compliant CSS rendered fine in other popular browsers.

No, that wasn't it. They didn't suck, and for a bunch of years IE was the best browser.

In the past there were no other options (no CSS positioning etc) so people used tables as a way to control content layout. They were actually pretty good for this, even though that's not what they were intended for.

Then CSS came along. Initially CSS was mostly exciting because it exposed a lot more fine-grained control over display properties like fonts, borders, margins etc than had been available in HTML attributes.

Gradually developers came to appreciate the value of what CSS was intended for - separation of content and presentation. Along with that realisation came the push for "semantic" markup, i.e. use appropriate HTML tags for the content, and stop using tables for layout (unless you are marking up actual tabular data).

For some years this was awkward though because CSS didn't provide good layout tools. So instead of true semantic markup you often ended up with "div soup" - lots of anonymous tags which exist just as containers for sake of achieving some hack with the CSS positioning system. And still a couple of things that had been simple to achieve with tables remained impossible.

But people persevered with the CSS hacks, for all the right reasons, until we get to the present day when I guess modern CSS has all the tools needed to produce any kind of layout, layouts that adapt to screen size, units that cope with Hi-DPI etc etc etc

But I think it's still appropriate to mark up tabular data in HTML with a table, and I would think they do a good job of that?

It took well over a decade to get CSS to play nicely with layouts. It's disingenuous to present CSS as the obvious solution to a problem while criticising table usage to implement grid layouts, as this line of argument entirely ignores the recent history of the web.

It's possible I interpreted that incorrectly? But if their problem is just making different layouts then I don't see what the issue is. CSS has breakpoints. You can already make different layouts for different screen sizes. You're not required to have one set of rules that apply to every page size.

The only criticism that makes sense to me as a reading is that they don't want a common set of UI paradigms and language features that allow targeting multiple devices and they want a more specific language targeted at describing a subset of those interfaces -- because that's what CSS is. That's the only thing that CSS is, it's just a universal rules-based language.

You can design different layouts for different page sizes, you can even on the serverside serve entirely separate HTML pages for mobile and desktop devices. The only issue I can think of left to complain about with CSS being too general is that CSS is a common language designed to be used in all of those situations instead of in only one of them.

Did they mean that they wanted CSS to have separate terminology and paradigms and ways to tackle those problems built into the language? It does! And that's exactly what people complain about, that's exactly where the "why are their 5 ways to do this" complaints come from, they come from CSS having lots of different ways to achieve the same effects based on the individual unique needs of the specific interface being created. What's the alternative, have one way of doing everything for every interface? The original commenter I was replying to said that they didn't want that.

They want multiple models for different formats, and CSS has that and lets you use them and target as many interfaces as you want, and there are ways to detect and serve different CSS and HTML based on device agents, and so... I don't know, if they don't want different languages, then what is the complaint?

This is an unfortunate misunderstanding. CSS did initially aim to provide at least same expressive power as presentational HTML allowed at the time. So it provided the display:table layout model so designers didn't have to use HTML tables for layout. Unfortunately Internet Explorer (which was dominant at the time) did not support this property for a very long time.

Floats were never intended as a general purpose layout tool, but ended up like that for designers which wanted to use pure CSS but at the same time had to cater to IE users.

While flexbox and flexgrid are more powerful and flexible, display:table actually support a lot of the layout functionality designers were clamoring for, like easy to implement expanding sidebars and such. The problem was not with the CSS spec but with the lack of support in the dominant browser.

haha are you serious? What percentage of people are using ie6 & 7?

I think that layout shouldn't be that complex - lets be honest here we aren't building applications or anything difficult like that - we're layout out text and pretty pictures and CSS often makes this more difficult than it has to be.

That being said I still use CSS as often as I can for layout.

But it's HTML, and should therefore should BE content. But it's not; it's presentation.

> I thought we discussed that browsers incompatibilities are the reason for this.

You seem to be missing my point. If CSS, as implemented NOW, worked as advertised and offered a way to separate content from presentation while retaining flexibility, then we'd have no argument. I'd happily be using it for what is intended. You just can't do that now, and I'm tired of people telling me that I can.

> I would hardly call this level of adding extra markup anywhere close to other HTML where the presentation is completely ingrained.

Of course it's not completely ingrained. But I want it to be able to be completely separated before I'm going to join your camp.

I think the fact that it took you (a CSS pro) 30 minutes to come up with a simple 3 column example that's hard for me to understand, reflects poorly on CSS. Just because something is possible doesn't make it a good technology automatically.

I might be able to make a Turing machine out of my blender, some rubber bands, and chewing gum (note: haven't actually tried this). It might be Turing complete, but I'm not going to be able to program anything useful with it (an admittedly extreme example)

Part of my work as a front-end dev. is taking pages from CMS softwares that are already done and add styles to them without changing any line of code on the markup.

I never, ever, had any issues.

You don't need to add extra divs to do anything.

In fact, when we learned to do CSS at college, the teacher teased the bad students. He would say that they had DIVitis. The great disease of our generation. Divs would keep popping up all over them and their work.

We currently support IE9+ without any issues. We used to support IE8+ without any issues.

Quite right. The argument, as I see it, is that it's much more practical to use the best cross-platform tool for the job, which in many cases is tables and not CSS. He's arguing that it's not worth the time.

> at least one follows a clear stated goal -- html describes the content, css draws the presentation.

This isn't even close to CSS Zen Garden's stated goal. Its goal is to show what is possible to do using CSS. It's goal is to be "A demonstration of what can be accomplished visually through CSS-based design." There's nothing about content/presentation separation anywhere on the site.

> but at least at the core we can see that HTML is purely being used to describe the content

That's certainly not what I see at all, especially at CSS Zen Garden, if that's what you're still referring to here.

> Allowing _enough_ separation required for programmers to be nearly clueless of a designer's job.

If you mean programmer == HTML, and designer == CSS, then this is simply wrong.

To be fair, CSS 2.0 (from 1998) has “display: table” which allows table layout in pure CSS. [1] The problem was not CSS. The problem was Internet Explorer 6; “display: table” was not viable to use until the early 2010s when IE6 usage finally plunged.

[1] Edit: CSS was designed for styled documents, such as online resumes or blogs. It was not designed to make interactive apps, which is why it doesn’t fit that paradigm well. Everyone thought Java applets would run the interactive web, and we would be making web applications in Java today if Microsoft had not killed Java on the web in the late 1990s with IE.