

When to use tables for layout - olavk
http://olav.dk/articles/tables.html

======
olavk
I get really annoyed by the recurring CSS vs. tables debates, because they
seem to be so dogmatic and often based on misunderstandings of CSS.

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.

------
jsdalton
HTML table elements are not the solution. They are a convenient hack that
happens to be the best alternative in 2008 because the majority of users is
still on an IE browser.

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.

~~~
olavk
IE7 does not support display:table either, so the long awaited dream is still
far away. Reportedly IE8 beta supports is though.

------
SirWart
Why not instead of blaming designers who use tables for layouts that are
nearly impossible to do CSS, blame the browsers (ie 6 and 7) that make these
types of layouts impossible under CSS.

~~~
pavelludiq
I agree that IE is to blame for the situation, but users don't care about
standards, they want stuff to work. life sucks

------
mbleigh
This article is missing the point...it is merely talking about when it is
CONVENIENT to use tables for layout, not when one SHOULD use tables for
layout. In a modern web world it is extremely inappropriate to use tables for
non-tabular data. Yes, this means that oftentimes there will be messy CSS
hacks to bring Internet Explorer into submission, but any designer/developer
worth his/her salt is old hat at such tricks by now.

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.

~~~
xlnt
> _In a modern web world it is extremely inappropriate to use tables for non-
> tabular data [even when convenient]_

Why?

~~~
mbleigh
Fair question. Semantically the <table> tag is created for just that, tabular
data. If you use it for layout there are a number of problems. First, it is
harder for screen-readers and other accessibility-based tools to decipher a
website laid out with tables than one properly laid out using standards-based
development. Second, you are adding needless bloat and confusion to your
markup, as you will have completely unnecessary tags littered throughout your
HTML. Third, you will be going against standards-based development, which is a
worthy goal in and of itself.

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.

~~~
dmoney
Perhaps the solution is to make a better screen reader, one that can extract
semantic data from non-semantic markup.

~~~
olavk
Yeah, screen readers seem pretty useless if they cant handle a web page with
tables-for-layout, since these are quite common whether we like it or not.

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.

------
bprater
Does it seem like we are still in the dark ages of web design and layout?
Lately, I've been excited that I can get away with using alpha transparent
PNGs on my sites, even though we've had the technology for the last decade.

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.

------
simonw
According to accessibility gurus that I know (proper ones who run real
controlled tests with screen readers, not just random people who read blogs)
using tables for form layout (as shown in that article) is bad, because screen
readers have "forms mode" and "tables mode" and a form inside a table forces
them to constantly toggle between the two, making it extremely hard to follow.

~~~
shawndrost
The world will not write code for screen readers. How about writing screen
readers that can read the code that the world wants to write?

~~~
simonw
That would be fantastic. The problem is that we're pretty much stuck with the
screen readers we've got - even when the screen reader companies do release
new versions (which they do painfully infrequently) most of their users stick
with their current versions because the upgrades are so expensive. If you care
about blind users (which you should; you're missing one of the great benefits
of the Web if you don't) you need to cater to screen reader versions that are
five or so years old!

~~~
tomjen
It is pretty pointless to care about blind users, since they can't use most
AJAX based sites anyway.

~~~
jonny_noog
I thought this was the whole point behind "graceful degradation". If an AJAX
based site does not degrade to still be useable/accessible when JS is off or
unavailable, then it's not that well desgined to begin with.

------
Wrestlevania
Using tables for form layout is a bit of a grey area--both in terms of "abuse"
and suitability. In my view, if you put your labels in TH cells and then you
corresponding form control(s) [see note 1] in adjacent TD cells - _and_ make
appropriate use of 'for' and 'id' attributes accordingly - this isn't such a
problem.

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.

~~~
olavk
What limitations in the CMS are you referring to? The limitations are not in
the CMS, they are in the browsers implementation of CSS.

~~~
Wrestlevania
I was making the assumption that a developer may have limited control of what
markup is being output by their CMS - if they were using one.

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!

------
kaens
"Using a CSS layout with floating boxes, the sidebar-box does not stretch to
the bottom."

"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

------
hobbs
"A foolish consistency is the hobgoblin of little minds"

\- 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.

------
irrelative
You could always use the layout tag to take care of the CSS pedants :-)

<http://www.codeirony.com/?p=6>

~~~
olavk
I know he is joking, but this would actually be a perfect solution if it
generated HTML tables for IE - and CSS with display:table for any other user
agent.

------
feverish
Dude hasn't heard of definition lists for forms? They offer far better screen
reader flow for disabled users than tables.

~~~
olavk
How do definition lists offer a better reader flow?

~~~
ajross
They don't. A table row has exactly the same recursive structure as a
definition list, and will be treated the same way by a screenreader. It's
kinda sad how many people like to play the "accessibility card" without any
actual understanding of how those technologies work.

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.

~~~
simonw
Apparently forms inside tables are bad for screenreader users because they
have to constantly switch between "forms mode" and "tables mode" to navigate
them.

~~~
feverishaaron
Bingo! Tables should be used for tabular data.

~~~
wvenable
Forms are tabular data -- headers on side, data on the other.

Screen readers should have long adapted to that scenario.

~~~
marcelvr
> _Forms are tabular data -- headers on side, data on the other._

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.

------
trotzke
Uh O... Thems may be fighting words.

~~~
xlnt
Judging from the article not the title, it looks like he is reasoning not
fighting.

~~~
trotzke
Sorry...Wasn't really meaning that he was fighting-- just that this thread
might get ugly.

