Layout tables considered valuable

Welcome to a holy war

There is a war in progress. It may involve millions of people across the world. Some participants set out to polarise opinions, exaggerate positions, and/or use psychological coercion to marshal resources to their side. These are the characteristics of a "holy war".

Millions of web sites in the world use tables to layout the major features of their web pages. Some people believe this is wrong. They articulate their views in books and papers, and across Usenet and the Internet. They appear to belong to two major regimes that have formed an anti-layout-table axis:

  1. One regime is fairly pure "anti-layout-table". Layout tables are wrong use of (X)HTML, or perhaps wrong use of anything based on SGML/XML, and should not be indulged in.
  2. The other regime is primarily "pro-CSS-positioning". CSS-positioning is right, and everyone needs to see the light.

These positions are not useful. They are actually fighting the wrong war. The solution probably lies elsewhere. There are 5 articles on this theme here, intended to establish a new baseline for this discussion.

Tables were introduced in HTML 3.2 back in 1997.... Purists, take note: Even back then, tables were expressly permitted "to mark up tabular material or for layout purposes".... The use of tables for layout has never been prohibited by the Web Accessibility Initiative. You are not creating an inaccessible page if it contains tables used for layout.... The idée fixe that layout tables are guilty until proven innocent – that they do not "make sense when linearized" by default, that you’re doomed to labour over them forever to get them working – is an urban legend. Take my word for it: Having used the Web since the days of Mosaic, I can assure you that most layout tables do make sense, whether rendered as graphical tables or when linearized. 

Joe Clark, 2002

"Building Accessible Websites" (chapter 10 - Tables and Frames)


Consider the use of HTML headers and tables as layout tools. When these practices appeared, in 1994 and 1995 respectively, they infuriated partisans of the SGML 'descriptive language' camp who insisted that HTML documents should contain only semantic descriptions and remain absolutely mute about layout. This in turn led to white-hot flamefests about how HTML 'should' and 'shouldn't' be used. It seems obvious from the hindsight of 1999, but it is worth repeating: Everyone who argued that HTML shouldn't be used as a layout language was wrong. The narrowly correct answer, that SGML was designed as a semantic language, lost out to the need of designers to work visually, and they were able to override partisan notions of correctness to get there. The wrong answer from a standards point of view was nevertheless the right thing to do. 

Clay Shirky

An Open Letter To Jakob Nielsen


Earlier versions of screen readers had great difficulty handling tables of any kind, so designers were discouraged from using tables for layout. The latest generation of screen readers now works more effectively with tables. In general, current versions read tables row by row, from left to right. As long as the contents of the page make sense when read across, you can use tables for page layout. 

Accessibility and Macromedia Dreamweaver


This, I believe, is one of the issues CSS advocates (including myself) don't cover that often. Truth be told, table-based layouts are currently more capable of handling this issue than CSS layouts are.... I'm certainly not advocating a move back to tables for layout. But unless dimensions are heavily manipulated by CSS, tables do work well at "containing" any objects placed within their cells. This, without needing to worry about content from one cell overlapping another, or a cell suddenly getting re-positioned below a cell instead of beside it. 

Douglas Bowman, Founder & Principal, Stopdesign

On Fixed vs. Liquid Design


Despite all of these completely valid points, it is still possible to use tables for page layout in an accessible and acceptable manner. 

Adaptive Technology Resource Centre, University of Toronto

Creating Accessible Page Layouts


It's only mark-up. It isn't sin! 

Barry Pearson, 2004

Where do I stand?

Do I have to say? I'm just an engineer! Why can't I be neutral, and simply provide analysis? But in a holy war, it is hard to remain neutral.

Paramilitary in Northern Ireland: "are you a protestant or a catholic?"
"I'm an atheist!"
"But are you a Protestant atheist or a Catholic atheist?"

I am in the solution business, not the debating business. I seek to resolve problems, not to perpetuate them by encouraging holy wars. I'm a sceptical freelance. I will impale anyone whose views don't appear to stand up to scrutiny. Too many views don't, and I show the evidence here.

Layout tables can be safe, effective, accessible, flexible, and future-proof. Use them sensibly, and your pages will be accessible to millions, even to disadvantaged people such as blind people, for decades. No mark-up police will break your door down and raid your property in the middle of the night. You are unlikely to be prosecuted under the Disability Discrimination Act (UK), or under Section 508 (USA), for using layout tables.

CSS (use of stylesheets in general) is a wonderful addition to the web. "CSS positioning" is an "incompetent system", which was not actually intended to replace layout-tables, and doesn't in every case. These pages here use CSS positioning, not layout tables, at great cost and anguish. While I was developing the templates for these pages, I was also re-engineering a large web site, and I used simple layout tables for the purpose. I did so because it had to be robust and predictable. It also has to be accessible, and use of tables made it "linearise" better than if I had used CSS positioning.

So where do I stand? The top two questions on my agenda are:

  • What do the specifications say? If you are trying to communicate with unknown products, the standards may be your only commonality. And "unknown products" includes those that haven't been written yet. Even the most strict and advanced standards support tables containing complex material, layout tables or otherwise. They do not, and cannot, distinguish technically between the varieties. There is no credible intention even to try to distinguish between them.
  • What works in practice, and is likely to work in future? I assume you truly want to communicate, and not simply have an excuse for why you failed to communicate. Layout-tables work well now and will continue to work in the future. CSS positioning sometimes works now, and should get much better in future.

Some people appear to believe that it doesn't matter about behaviour and prognosis. They appear to believe that layout-tables are simply wrong. That sounds more like "religion" and "sin" than "engineering". It's only mark-up; it isn't sin!

What is a simple layout table?

What is the alternative to CSS positioning that we should compare it with? Is it some awesome set of nested tables with lots of presentation attributes and spacer-GIFs? No! (If that were the only objection, we would be on the same side). We can layout a 2-column page starting with a table such as this:

<table id="twocolumns"><tr>
<td id="sidebar"> navigation etc </td>
<td id="maincolumn"> main content </td>
</tr></table>

What HTML would we use instead of such a table if we are using CSS positioning? Perhaps:

<div id="sidebar"> navigation etc </div>
<div id="maincolumn"> main content </div>

But sometimes it may be necessary to wrap up the content for some reason. Perhaps because we also have other things to position, such as a header. Perhaps for some style reason, such as controlling floats in order to have sensible borders. So we may actually have mark-up like this instead:

<div id="twocolumns">
<div id="sidebar"> navigation etc </div>
<div id="maincolumn"> main content </div>
</div>

A holy war is being fought on the differences between these sets of mark-up!

Were "tables" intended only for tabular data?

I ask this question because some people appear to believe it is important. A response to someone who describes their current attempts to develop a web page may be "that isn't tabular data - don't use tables". In fact the question is irrelevant. Human beings dominate the planet because they are adaptable & creative, not because they stick to predetermined intentions.

But, in fact, tables were always intended to layout content in a horizontal and vertical formation. Any valid content, which from the start has explicitly included complex material including text, multiple paragraphs, lists and headers. The current proposals for tables in XHTML 2.0 still explicitly allow such complex material in table cells.

The key point is - using tables for layout is not a bug. It simply says "don't enquire about the semantic relationships among the data here, just treat it according to the specification for <table>". Table-layout people are not asking for special treatment - just to be treated according to specification! There is no reliable way of identifying whether a table is used for layout purposes or other purposes. Such a distinction may not actually make sense! Look how some people try to know whether it is tabular data. "... the page author should be able to do so". "If you can't state what the column headers are for the table's columns, then it is not tabular data". In other words, the distinction between tables for layout and tables for other purposes isn't something concrete, it is supposition about what authors are thinking. You and I could have identical content. We could mark it up with <table> in identical ways. But if I was ingenious enough to be able to think what the columns mean, and you were not, my table would be for tabular data and yours would be for layout!

No one is about to stop table-layout from working. The key is that it doesn't actually need extra features. It simply uses features that are there anyway. There is no algorithm that will even reliably detect that someone is using table-layout. That is why it is safe.

In 1997 the W3C said "Tables should not be used purely as a means to layout document content as this may present problems when rendering to non-visual media. Additionally, when used with graphics, these tables may force users to scroll horizontally to view a table designed on a system with a larger display". They stated a couple of problems, and said how authors should (not must) avoid them. But in 1997 there was no alternative available, and neither reason is now important enough to require such an injunction, because suitable technology is now available.

Since 1998, non-visual user agents have got better at handling tables. I've been using IBM's Home Page Reader, and it was able to "linearise" through tables. Opera 7.2 in "small screen mode" shows that user agents in principle have the option of mapping table-layout onto small screens. So things have moved on a bit since 1997. In 5 years time, they will have moved on more. Also, some of the browser problems we have at the moment with CSS positioning will be less important. The balance between when to use table-layout and when not to changes year by year. There may not be a clear date at which we can say "now it the time to stop using table-layout". Support for both table-layout & tableless-layout is improving.

Practical behaviour of layout tables

Here are some known behaviours of layout tables, with evidence provided at this site:

  • Pages using layout tables can "linearise" well, with the main article appearing before the site navigation and other other links.
  • On average, layout tables add perhaps 25 bytes or so per unit that they are laying out, compared with alternatives.
  • Modern browsers can handle layout tables with very flexible widths, typically with better superimposition-behaviour than they achieve with tableless layouts.
  • It is possible for a browser to successfully display pages controlled by layout-tables on a 240-pixel screen, such as mobile technologies. (For proof, try using Opera 7.2 in "small screen mode").
  • Layout tables only define a default layout. CSS can go as far as disabling tables and making the content behave as required. (That is what Opera does). So layout-tables do not forever constrain the content. They simply suggest defaults.

Statistics on the use of layout tables

The vast majority of authors in the world aren't fighting a war. They use table-layout because it works. It made the web a much more interesting place, and led to the development of tools such as Fireworks & many others that could exploit tables to make the web look very interesting. The success of the web is probably partly down to the exploitation of table-layout. Those authors may not even know there is a war. Even if they know, they are not threatened by it.

I estimate news sites are publishing about 100,000 pages or more every day. The overwhelming majority of these use layout-tables. The notable exceptions are Wired of course, and c|net news.com, and .... er .... (gosh). Perhaps between 100,000 and 1 million layout table pages are published each day, successfully. That is the true nature of the web. Now, and probably for several years.

The web is dominated by table-layout. Until it becomes far easier to use CSS positioning, eg. much better tools for Joe-public to use, it will continue to be. Therefore, user agents will have to support table-layout for decades! And that means in all sorts of situations - non-visual UAs, small-screen UAs, etc. What else can they do - stop handling nearly all of the world's useful content?

The CSS-positioning evangelists are playing a useful part in helping us understand the advantages & disadvantages. But when they step over the line and say "layout tables are wrong", rather than simply striving to show that "CSS positioning is better", they are making a mistake. And they weaken their case when they attack tables. It makes people like me suspicious. I wonder if the main justification of CSS-positioning is that tables are claimed to be bad, rather than that CSS-positioning is good. I set out to test their claims about tables, and typically find they are exaggerating.

Discussions

For a lot of the things we do in life, we have central policies, then these are interpreted locally. Fine. (Imagine sending either the specification or the source-code for a program). For other things we do, the details are generated centrally, and they are operated locally. Fine. (Imagine sending the instruction code for a program). Those models work.

But the web is a bit weird. We don't transmit the policies, we transmit the details. But the details are not always, or even often, operated locally as centrally defined. We send the instruction code, but the local system is likely to ignore bits and handle other bits in strange ways. It can't know whether it is doing so in accordance with our original intentions or not, because it can't discover what those intentions were. Something is missing. I don't know what the answer is. It certainly isn't HTML 4.01 (or XHTML 1.1) and CSS2!

Laying out material in a grid format long predates the web. I don't know how strongly it is tied to Cartesian coordinates, but Descartes came up with those over 350 years ago. Was it a "useful idea" that became culturally adopted, or an inate aspect of human nature that became formally recognised? It simply appears easy to scan horizontally and vertically to find related information - or the next musical note! Blakemore (in)famously showed that kittens' brains became hardwired for seeing horizontal & vertical lines quite early, and I guess we are the same. I remember reading about research that suggested that people brought up in communities without lots of vertical and horizontal lines see things quite differently.

Perhaps it isn't "horizontal" and "vertical" that are important, but "juxtaposition". We want related stuff close together. Authors tend to form views on what users should see (or hear) in juxtaposition in order to extract maximum meaning. In 1 dimension this is structural mark-up, and it leads to a conventional layout. But the author may want structural mark-up in 2 dimensions, and the only way we have is a table. Perhaps instead of seeing tables as something very different, we should wonder why we don't simply use 1-column tables instead of current structural mark-up. Why have we got 2 different methods of having headers followed by information? Why don't we have <th1> ... <th6> tags? It might allow user agents to fold & hide rows & columns.

The only real war worth fighting is "CSS versus no-CSS". It makes sense for every web page published to link to an external style-sheet. Then authors can evolve their material at a suitable pace, as development tools & user agents & their own skills evolve.

Table-layout is perfectly sensible, and will be for a decade or two. What we need are rational choices for different levels of complexity, different degrees of browser-dependence, and different levels of skill. If the proponents of different approaches would stop fighting, we could have mix-n-match solutions available to people of all skill levels and all target-browser combinations.