Logo for "Nota Bene / non-blog" goes here. NB main page

Along with navigation links.

Second Thoughts On the Evil of Tables

Trendy Philosophy

1 June 2007

Old web design layout was done with tables and only tables, with a high degree of hackery and tricks to make it turn out right. This included other evils such as invisible images and forcing specific sizes of elements in pixels.

Another evil that has plagued the web has been pixel-based specification. With higher resolution displays, I too-often see microscopic print that cannot be resized, or a page that lets me resize the text but keeps the same absolute width of the column.

The current state of the art avoids tables at all costs, with the cost usually being that this second problem is only partly addressed. Multi-column layouts, as the current fashon goes, will have resizable text and at best a liquid main content column, with other columns either being sized as absolute pixels or a percentage of the screen.

My Design Goals

What I want is to have one or more “secondary” columns that are sized according to their own contents, or if explicit, expressed in em units. The size must not be expressed only in pixels, or in percent, which don’t consider the actual needs of the content.

Meanwhile, the “primary” column should size itself to whatever space is left after allocating space to the secondary columns. When resizing the window, the primary column will accept the change. When changing text size, the secondary columns will change to match and the available room for the primary will be recalculated.

Availability of Features

Floating elements (usually div’s) in CSS2.1 simply does not do that. The secondary columns can be sized explicitly using em units, and maybe work with self-sizing based on the content.

But what about the primary column? If left alone, paragraphs will flow around the other columns but only to the actual height of those columns. If you float the primary column too, you have a dilemma: The natural width of flowing paragrahs will be the full width of the parent, not the leftover width. It must have an explicit width given to work as intended. But what is the width? You cannot specify a formula of parent size minus these other items.

Other ways around it run into the same problem. Give a margin to avoid the secondary columns? Again, you cannot come up with the proper width to specify it!

So, designers give up. They will either specify the primary column as a fixed size too, or specify all columns as percentages.

Conflicting Goals

My thesis is that the first goal, not to use tables for page layout, has taken absolute precidence over the second goal, which is to let the browser have control.

Is that even the right precidence of the conflicting goals? The casual reader of the site will appreciate the control, and not care about the markup used, unless it makes loading slow.

We need to prioritize the goals, and reconsider the absolute ban on table elements for page layout.

Absolute Evil Or Just a Tool?

The essence of the former misuse of tables is that they were mis-used. For so many things, CSS will work better. Tables were bent to a task, hacked into doing things they don’t naturally do, often with nonportable results.

But, sizing widths to fit a page is exactly what tables do do. Consider: A table can be given an overall width such as 100% of the parent element. Each column can have its size determined by its content, with well-defined behavior even without an explict width. And finally, columns without a specified width will take the remaining space based on the overall width. As a second benifit, the height (background color) will be the same across all thee columns, something else that needs elaborate workarounds with in CSS.

This is what tables are for. Even a table with one row, one td for each column, is drawing upon the unique behavior of tables, and certainly not bending them to work in ways other than what they were meant to do.

Now look at what you do to avoid using tables. Hacking CSS and messing up the layout with dummy wrapper elements? Does’t using a negative number for a margin sound like a hack? Designers are trading tricks and highly-evolved techniques just like they were for table layout in an earlier age!

Maybe we’ve come full circle, and it’s time to properly apply the right tool for the job, rather than avoid a perfectly good tool because it was overused in the past. The proper use of a table element should be defined not by a vauge “it contains data that is tabular” but by the unique layout features that the element provides. I don’t need the feature of cells that stack up vertically, as there is only one row. But I need the feature whereby it knows that a set of cells is related and grouped under a global constraint.

Moving Forward

What inspired me was a hypothetial conversation with the (personified) engineer in charge of CSS. I said I wanted a feature to do thus. He said that there is already something that does that, so they won’t add a new construct that does the same thing.

That might be the fate of a CSS feature that is specifically and souly designed for laying out columns. But CSS could have more general mechanisms, and can have the missing features addressed.

An obvious thing would be to allow simple formulas in widths. Better would be a general grouping mechanism where several boxes can be told to coordinate their fit. This would do what the table row does, plus much more.

In the mean time, I have to use the tools I have, and will think seriously about letting tool culture trump end-user requirements.