At Cre8asite Forums this week, a lengthy discussion on the ultimate value of pure CSS (Cascading Style Sheets) (Cascading Style Sheets) based layout over the use of tables has been taking place. Sometimes, living in the sheltered world of accessible and standards-based design, I can lose touch with the fact that many people out there simply don’t accept some of the same guidelines I work with every day — and that this does not, in any way, mean that they haven’t given the subject a fair shot. Very good arguments have been made to defend each side.

On the whole, I think this discussion is an old, worn-out subject: those who won’t use tables generally don’t use them out of principle, and those who do use them out of pragmatism and a justified awareness that principles don’t build websites. I want to review the question once more, however, ignoring the entire question of principle.

The Argument Before Us

The question at hand in this forum discussion has been whether tables have a fundamental, universal flaw which should make them unacceptable. Many arguments have been offered, but don’t satisfy the true question.

Answering the question is actually very difficult. It needs to be an inherent characteristic of tables, rather than a factor which depends on a specific use of tables or a facetious argument about which one is “easier” to use or maintain.

I’m opposed to using tables for layout — but now I want to look very closely at why. I want to find a reason outside of my own biases and beliefs, which can be simply stated and demonstrated.

Is it possible to use tables for layout and provide an equally usable and accessible web site?

For the best analysis, we have to assume that these tables are being used in a respectable manner. Bad code is bad code, whether it’s applied to <div>s or <table>s. Twenty-eight layers of nested anything is bad news.

So, there are three rules which must be met in order to be a definitive advantage:

  1. I’m not willing to accept minor design limitations as meaningful for either option. Whether there are certain design choices which you don’t have open to you with tables or with CSS-based layouts is irrelevant to me: you choose a tool, and work with the capabilities of that tool.
  2. I don’t accept ease of maintenance of development as being relevant. These are personal opinions and personal choices.
  3. I’m not going to consider semantics except as it may effect the user experience. A context in which the use of tables for layout causes problems because the device assumes any table is purely tabular data is a problem; the argument that tables are “wrong” for layout is functionally meaningless.

The only acceptable argument is whether there are ways in which the use of a table for layout inevitably damages the user’s experience with that site.

Examples of perceived weaknesses of tables

Speed of rendering. Unless table widths are specified explicitly, the entire content of the table must be rendered fully before the browser can completely render the page. This slows down the overall loading time of the page.
This does not fulfill the requirements. First, this is also true of CSS based websites. Second, it’s avoidable.
In order to provide an accessible website order, you have to arrange your data cells very carefully, due to table linearization.
Partial pass. The only real difference is that with tables, whatever will appear on the left MUST be before what appears in the center. Of course, there are easy workarounds for it. There are, in addition, many other ways of navigating around a page which make the whole concept somewhat irrelevant — it doesn’t ultimately matter that much whether your navigation appears before your content, if you’ve made effective use of other key structural elements or skip links.
Adaptability with variable browser widths
Tables can only become as narrow as the content they contain, even if they are constructed using percentage widths, etc. Div based layouts can re-flow content, so that sidebars slip to the bottom as the screen width narrows. The question is: which behavior is worse? Would you rather have to scroll to the bottom to see sidebar or navigation content, or scroll horizontally for the same? I’d rather not ever do horizontal scrolling, but this isn’t a clear pass.
Compatibility with mobile devices.
Technically, the same problem as above. However, many modern devices don’t really have this problem. There are four basic methods of rendering sites in mobile devices: linearizing, zoom, rewrite, and “try and interpret the standard styles on a tiny screen.” The 4th method is the only one which is likely to really run into problems with tables — and it’s fundamentally identical to the previous described problem.
Ability to accomplish radical redesign without altering HTML (HyperText Markup Language) code.
Depending on your definition of radical, this is a total winner for CSS layouts. Tables fix the fundamental placement of elements where CSS based layouts allow those fundamental elements to be moved more or less at will. Whether this is seriously important, however, is a matter of personal opinion. Arguably, this is a question of design capabilities, and fails rule #1.

That’s all I can think of off the top of my head, although I’ll happily accept suggestions from the comments.

Before I move on, however, I want to approach this from the opposite direction. What are the advantages to using tables for layout? The same rules apply: only a situation where not using tables for layout damages the user’s experience will absolutely qualify the table as a superior method.

The main reasons people have so far espoused as benefits to using tables for layout include:

This is actually a very interesting problem, which clearly exposes some of the weaknesses in CSS: specifically the lack of ability to specify that a block level element is centered without specifying that the text within is centered. I’ve constructed an example, but it only functions in browsers which support display: table. Opera and Firefox make it fine, as does Safari — but Internet Explorer, as usual, falls short.

Easier to learn and use
Matter of opinion. Doesn’t qualify.
Easier to create a multi-column layout with full-length columns.
Yes, it’s easier. But the fact that with CSS this is quite difficult is not a huge advantage — although we ALL agree that CSS will benefit greatly from more advanced support across browsers.
Certain layouts are only possible using tables
This is extremely difficult to prove. In the Cre8asite thread, Ron Carnell suggested a specific layout which he believes is not possible to accomplish without using a table. The challenge is to present a poem with a heading where the lines of the poem are left-aligned, but the poem as a whole is centered under the heading. The poem and heading should be able to have lines of any length and still remain centered correctly. (See “flush left” sidebar.) Although CSS appears to fail this test, the test itself comes under rule #1, as well. It does not substantively effect the user experience.
Browser Compatibility
Older browsers have lousy support for CSS. This is pretty much a no-brainer. Older browsers (Pre-IE (Internet Explorer) 5.5) pretty much just have to receive style-free versions of CSS-based layouts. Still, it’s a very valid question whether providing support for Netscape 4.8, IE 4 or similar relics is actually valuable. As of today, statistics for August 2007 at theCounter show that all versions of Netscape 7 and below plus all versions of Internet Explorer version 5 and below accumulate to approximately 1% of browser market share. Versions of IE in the 5 range account for over half of that – but it’s still less than 1%. (Browser Statistics for August 2007 as of August 23rd, 2007.)

In Conclusion

The conclusion, so far, is inconclusive. Tables, when used with a high level of consciousness concerning how and when they can be used, can provide a perfectly flexible, fast, web site. Though there are definite flaws with tables and how they present information, many of these problems are paralleled by related problems when using CSS based layouts.

There don’t appear to be any serious benefits, however, to using tables for layout. Although the table may make layouts easier for certain contexts: particularly when using centering and fluid widths or establishing full-length columns, these aren’t, in my opinion, issues which are capable of selling the table as a tool for layout.

In the absence of any definitive benefit for either tool, I will choose not to use tables for layout. I am, however, interested in this argument, and would be glad to hear your own arguments for or against either method. I have little doubt that I’ve missed cogent points for both sides!