When to use tables for layout
olav.dk
olav.dk
CSS was initially designed to support every kind of typography or layout which was achievable using presentational HTML. It was rightly recognized that if some effects (no matter how ill-advised) were only possible using presentational markup, people would not migrate to CSS. This is the reason properties like "blink" were included in CSS.
Regarding table-like layouts, the corresponding CSS property is called "display:table", and was included in the CSS 2.0 standard 10 years ago.
IE however did not and does still not support "display:table". Therefore there is no direct CSS alternative to table-layouts which works cross-browser.
A table-like layout can still with some effort be emulated by pushing other CSS features like floats to the limits. But this is actually misusing these CSS construct for a purpose they were never intended for, which makes it generally convoluted and inflexible compared to "just using tables".
But it is important to realize that the problems with the CSS approach is not that CSS is badly designed - or requires a fundamentally different mindset - but simply that the implementation in IE is incomplete.
One should also realize that tables are superior only in some specific circumstances (as described in the article). Generally CSS is better and easier to use for layout, even considering the omissions in IE.
In fact, it is quite possible to get table-like layout behavior while using semantically correct tags. This is accomplished through the various display: table-type CSS properties.
As support for IE6 fades this long awaited dream will quickly become a reality.
The proper time to use tables for layout is when one is laying out out a table. If you aren't, then you are simply performing a cop-out maneuver to save yourself time in website development. If that's what you want to do, do it, but don't call it something it's not. Just because it's easier doesn't mean it's better.
Why?
CSS exists to separate markup from style information, that's its entire purpose. To use tables to lay out a page is to explicitly include style information in a place designated only for semantic markup.
A sensible heuristic would be to treat tables without TH or THEAD elements as layout-tables, ie. just read them serially, while treating tables which contain at least one TH-element as a true semantic table. I'll bet this is the correct interpretation 9/10 times.
I was like you ~3-4 years ago as I grew up using tables. Believe me, just move on... 99% of the job postings I see require an understanding of XHTML/CSS. And this trend will continue as standards are solidified...
Catch up or be left behind.
Unlike you, I clicked on your profile and read a vast majority of your comments. You should go back to lurking, and spew your negativity and snide remarks elsewhere...
unlike you, i have no interest in your profile.
Your post does not constitute more "maintainable" code at all, and contradicts the years of community contributions to CSSZenGarden. I'd recommend you establish a personal CSS "framework" for tackling common layouts/frustrations.
It's ok to be a conformist in this regard.
Oh no, you mean everything I've read here in the last 482 days has been displayed in "extremely inappropriate" mode?
Look: can tables be misused? Yes. Have they been? Yes. Does a static HTML file filled with tables for layout obscure the semantics for things like screen-readers? Sure.
Does any of that have anything to do with whether or not a table should be used for layout? Not that I can see. Two or three lines of jQuery will pack those divs into your table by class.
The weirdest part of all of this is the idea that CSS is "just as good" for typical layout tasks. Not only is it not as good, it's a near-disaster. Nothing works right, ever. It's never possible to just say "line these elements up and put these others to their side" without jumping through awful hoops. Seriously: look at the "layout" CSS for any serious site and it's almost unreadable.
GUI developers have understood this for two decades now, and universally settled on the table as the appropriate layout mechanism. Why the web should somehow be different just baffles me.
If you want to change the layout of any site, you need access to both the html and the CSS, so trying to separate the two is just overkill. Sure, you'll want to use CSS for colors and fonts, but for page flow, CSS isn't powerful enough by itself.
This approach will never work on "real" web site, because content on a real web site changes.
That is why tables fare better in "the real world" even if proof-of-concepts like zen-garden seem to demonstrate that CSS is powerful enough.
As far as your column example is concerned, you made two content areas dependent on each other when that relationship may change overtime too, however with tables... you must recode the entire site structure to adapt to that.
A couple of years ago, I ran a styleswitcher on my blog giving the visitor about 5 layouts to choose from. Each one visually different from the rest, not one of them needing any changes to the HTML. The content changed on a daily basis (every time I wrote an entry) and yet it still managed to fulfil its purpose.
Sure, it was only a blog and not a commercial website, but it still shows that CSS is capable of changing the layout by itself. Perhaps sufficient CSS experience is the key?
Someone once said (in an admittedly totally different context) that '"Inappropriate" is the null criticism. It's merely the adjective form of "I don't like it."'
From the moment I began to learn HTML, I've been busting my head against this 4x4 beam standing here. The beam is bloody, but I'm still struggling with things that should be ultra-simple.
We have a variety of prior work we can use to investigate better layout strategies, namely from the print design/layout world and from the programming world, where we have layout managers a-plenty. It really is frustrating.
However, using tables for general page/columns layout is ignorant. It also highlights fundamental weaknesses in your page designs to begin with; if you need to use tables to get around the "limitations" of your CMS, you should be educating your designer(s) as to what is and isn't possible.
In my experience, with considered design and type-setting - plus the "background to create appearance of columns" trick - there's nothing you can't achieve with semantically rich, minimalist markup.
I've been able to depend on the 'One True Layout' CSS columns framework since its inception and have yet to encounter a columnal page design it couldn't handle cross-browser.
[1] You need to be careful with things like groups of related form controls, however--such as radio buttons. These should always be displayed using a fieldset, along with an accompanying legend, which means tables aren't particularly suitable for semantically arranging this sort of complex interface. For things like simple login or user profiling forms though, I think tables are arguably an OK construct to use. But I never do, personally.
You can't always nail down every last character coming out of a framework, should you be using one, no matter how great it might be.
Anyway, as I said: it's not so much a problem using tables for form layouts. But I encourage you to look at pure CSS solutions for column layouts (such as 'One True Layout').
You obviously care about what you're producing, you should keep pursuing purer, more semantically rich (and appropriate!) markup.
If you want to discuss this one-on-one, you can get me via Twitter:
http://twitter.com/Wrestlevania
Look forward to hearing from you, Olav!
"The solution proposed by CSS gurus seems to be to create a background image with a colored area overlapping with the sidebar-area"
What about height: 100% with a dom layout something like:
div#wrapper
div#header
div#main
div#sidebar
div#main content
div#footer- Emerson
That is, using div vs. table or vice versa, just because you're "supposed to" strikes me as being contrary to the true hacker mindset.
What screenreaders do have trouble with, however, is static layouts where the "meaningful" content is buried six levels deep, and often at the end of the logical document, just to make room for a bunch of navigation aids and advertisements.
That, however, isn't a reason not to use tables where they help. Also, note that with just a tiny amount of javascript it's possible to come up with a document that displays in a nice table layout and has a nice logical structure for screenreaders. It just requires that you get beyond the pedantry of the table.
Screen readers should have long adapted to that scenario.
For very simple form designs, sure. But that idea breaks down when you have a more sophisticated form and need to consider horizontal "flow" between fields.
Tables are hammers, but not all forms are nails.
I challenge the hackers here to find a way to teach this to the CSS diehards. I often wonder why the accessibility of CSS based layouts is often preached by the same people who make Flash sites.
This might be the case, but it would be really interesting to hear something about it from someone who actually have real-world experience with them.