A Table for One

We used to use tables, which worked well in this scenario—but forms don’t constitute tabular data, so it’s a semantic faux pas.

Nick Rigby, A List Apart

I know this sounds absurd, but I've been burning the midnight oil trying to come up with a new way to do HTML forms.

The ideals of CSS and DHTML say that programmers should not use HTML tables in design. Every single form I've developed uses tables. I want to be a good programmer ... so I've thrown in hundreds of hours to figure out how to do it the right way. Unfortunately, not a single one of the CSS/DHTML methods I've found for formatting forms has the elegance of placing the form in a table.

For nonprogrammers, here is a short summary of the conflict: In the first versions of HTML there was no way for web developers to set the margins on a web display. To make matters worse, the web browsers of the day scrunched the text of a web page against the edges of the browser, making pages hard to read.

It just so happens that HTML included table elements. Programmers quickly learned that they could overcome the shortfalls of HTML by putting all of the text in a table, and giving the table a margin.

Later versions of HTML included layout boxes called divisions and a layout language called CSS. The standards organizations then went on a crusade to remove tables from web design.

In a classic story of over reaction, the intelligensia went on a crusade to remove all tables from web pages. The ideal was to develop web sites with absolutely no tables. Group think dictates that the presence of a table in a web page is a sign of a second rate programmer. I admit it. I actually feel less of myself because I can not figure out a good way to make a form look good without using tables.

Anyway, while working late night sessions trying different ways to replace tables it dawned on me: The reason I want to use a table in HTML forms is because forms are, by their nature, tabular data.

I came to this realization simply by stepping back and looking at what I was doing:

I am first and foremost a database programmer. The web pages I design are generally about putting data in tables and displaying that data. In most cases, the purpose of the web form is to gather a row of data to place in a web form.

In database programming, you often find yourself working with a single row of data. A table with a single row of data is still a table.

It is customary to present tables in a top down fashion with the headers of the table in the top row and the data in rows. There is no universal law against displaying the data horizontally ... that is with the headers in the first column and each row in following columns. When dealing with a single data element, it is often cleaner to display the data in the horizontal fashion. For that matter, most drill down reports will display a table with rows of data. When you click on an item in the list, you will see the detail listed in a horizontal table. (eg, here is a list of books I've read recently. If you click on a book, the program shows the detail in a horizontal fashion.

A form is really just a blank row of tabular data.

Yes, using tables for the primary layout of a web page was a misuse of tables. The mania to replace all tables in web design with divisions was a similar misdirection. Using divisions and labels for displaying tabular data is as much a misuse of the technology as using tables for divisions.

Good web design is about using the proper design elements at the proper time. Reviewing Nick Rigby's comment: "We used to use tables, which worked well in this scenario—but forms don’t constitute tabular data, so it’s a semantic faux pas."

Nick Rigby and thousands of web designers have put themselves through a great deal of brain damage on the false premise that forms are not tabular data. For that matter, I contend that the reason forms and tables worked so well together is because forms are tabular in nature.

I wish I could get back all the time I wasted looking for ways to program forms without tables.