The Tableless Table
And when we have tables,
we will need lines in them of various types,
and column headings and things.
And it will be good […]
– Tim Berners-Lee, 1993
A brief history of the structure-presentation dichotomy and the table tag; a few code examples are available here.
Armin Wagner, January 2009
The separation of structure and presentation is generally embraced as the fundamental design principle of HTML. This article gives a brief introduction into the historical background of this dichotomy, focussing on one specific element which caused confusion since the very beginnings of the World Wide Web: the ominous
Before the concept of hypertext could re-emerge out of the post-structuralistic “crisis of representation” at the European Organization for Nuclear Research, markup languages had to be developed first. An early document entirely devoted to this topic is the technical report written by Charles F. Goldfarb at the IBM Cambridge Scientific Center. In “Design Considerations for Integrated Text Processing System” Goldfarb defined formatting as “the process of determining the visual representation a document will have when it is output from the system and displayed”. Instead of typographic commands put between the words, a generalized markup language should offer system independent mnemonic tags providing a description of the document's actual information structure.
For example, consider marking up a technical report for formatting. The user (often without recognizing it) first analyzes the information structure of the text. That is, he identifies each given section of text as a paragraph, a heading, a table, or some other predefined type. He must then determine, either from memory or a style book, the commands which will produce the format desired for that type of component.
Unfortunately, his next step is to put the commands themselves into the text, thereby losing the information about the document structure.
For example. if he decides to center headings and photo captions in this application, all that will appear in the text is a center command, with no indication whether the text is a heading or a caption. If in a future formatting application he decides to left-justify the headings, he will have to mark up the text again by hand.
Similarly, if he wishes to use the document for information retrieval, he will not be able to distinguish the text of headings (which might be very significant in information content) from the text of anything else that was centered.
For Goldfarb marking up a document means to identify and relate all textual information, to describe a structure, not a specific appearance. During the automatic formatting process the structure gets “portrayed”, the document gets “represented” according to the settings of the viewer's display device. This isn't always a lossless transformation, as differently marked up parts of a text can be presented the same way. Therefore the structure of a document is only ambiguously “reflected” in the format of the printed text. Typographic choices are only imprecise indicators of what lies beneath.
This specific perspective on looking at text brought several benefits, especially a certain degree of cross-platform compatibility and maintainability. Most important, markup languages made the old conventions of printed text useable for automatic text processing.
HTML, as one of the very first pages on the World Wide Web dating back to the year 1992 mentions, is based on the Standard Generalized Markup Language. Accordingly it inherited several design decisions, as well as the benefits and problem areas stemming from them. Later controversies were already anticipated in the following summary:
An SGML document is marked up in a way which says nothing about the representation of the document on paper or a screen. A presentation program must marge the document with style information in order to produce a printed copy.
[…] However, some authors feel that the act of communication includes the entire design of the document, and if this is done correctly the formatting is an essential part of authoring. They resist any attempts to change the representation used for their documents.
While SGML researchers wrestled for several years with feasible table models (see: www-talk and CALS Table Model History) and the concept of style sheets, first attempts of presenting tabular data in the World Wide Web were based on the usage of the tab-key and the space-bar together with the tags
<xmp>. Those tags were replaced quite soon by the nowadays established
<pre> tag, which marks a passage of preformated text. Within such a passage traditional typewriting layout can be implemented by using whitespaces and a monospace typeface.
However, quite early debates started about the structural information these whitespaces might possible convey. In the year 1993 Dave Ragget, later W3C fellow, announced the following development objectives on www-talk, a mailing list devoted to the development of WWW software, followed by an enthusiastic respond of Robert Raisch, working for O'Reilly & Associates:
From: Dave_Raggett (email@example.com)
Date: Tue, 27 Apr 1993 12:34:39 BST
Subject: Standardizing new HTML features
In a recent phone conversation, Tim Berners-Lee suggested I take over editing a new DTD for extensions to the current HTML spec. Don't get worried - the existing HTML tags will continue unchanged. […]
The features to consider include:
- nested lists (e.g. OL within UL, UL within DL, ...)
- embedded images with text flow etc.
- query forms
- other features ...
From: Rob Raisch
Date: Tue, 27 Apr 1993 17:19:05 -0400 (EDT)
Subject: Re: Standardizing new HTML features... WE'RE INTERESTED!
O'Reilly and Associates is *extremely* interested in helping you with this effort. We have a number of products in development which use HTML as their technology base. We see the future development of HTML to be of great importance to our efforts.
[…] I believe that HTML, like its progenitor SGML, should be simply a method of describing data, not how it should appear on the screen. In fact, I think that this is exactly the sentiment which Tim Berners-Lee has expressed to us all regarding his vision of HTML.
[…] <HYPOTHESIS> A form or table cannot be specified in HTML without breaking one of HTML's first principles since forms and tables are descriptions of the appearance of information in relationship to other elements and not the description of information in terms of type and content. </HYPOTHESIS>
[…] <ASSERTION> The organization of information into tabular form is intrinsically a render-time issue, not a representational one. </ASSERTION>
In June 1993 Raisch wrote “Stylesheets for HTML” and proposed to give the browser suggestions so it can render a document in “a form which more closely resembles the document as envisioned by its creator” including vertical and horizontal object placement as well as multi-column layouts.
When O'Reilly finally launched one of the first web portals in the WWW whether tables nor stylesheets were available. To accomplish multiple columns, prerendered images had to be used. But the parallel development of the HTML table model and stylesheets had already begun.
4. HTML 3 and CSS1
While early browsers started to support the
<table> tag, the concept found its way into the HTML+ Discussion Document and the RFC1942. Tables were considered a hope for the visually impaired “setting to rights the damage caused by the adoption of windows based graphical user interfaces” (Compare: HTML 4.01 specification, Appendix B). People should stop using the tab-key in combination with the
<pre> tag. And the HTML table model should get attributes for labeling cells so they can be presented by text to speech conversion software.
However, a certain uneasiness about the role of the
<table> tag remained and got finally addressed in the working draft of the HTML 3.0 table model, edited by Dave Raggett (Again, compare: HTML 4.0 Specification, Appendix B for quite similar clarifications):
It is generally held useful to consider documents from two perspectives: Structural idioms such as headers, paragraphs, lists, tables, and figures; and rendering idioms such as margins, leading, font names and sizes. The wisdom of past experience encourages us to separate the structural information in documents from rendering information. Mixing them together ends up causing increased cost of ownership for maintaining documents, and reduced portability between applications and media.
For tables, the alignment of text within table cells, and the borders between cells are, from the purist's point of view, rendering information. In practice, though, it is useful to group these with the structural information, as these features are highly portable from one application to the next. The HTML table model leaves most rendering information to associated style sheets. The model is designed to take advantage of such style sheets but not to require them.
The draft for the Document Type Definition proposed attributes for direct control of alignment, column widths and text flow, offering “control over appearance which would be inconvenient to express exclusively via associated style sheets”. The shortly after published W3C recommendation “Cascading Style Sheets, level 1” stated rather halfhearted that CSS1 “does not offer a layout language” and “does not offer multiple columns with text-flow, overlapping frames etc.”.
5. HTML 4, CSS2 and the WCAG1
A few years later, in the advent of the commercially used and fast expanding “Information Superhighway”, the main challenge shifted from the representation of technical papers to the presentation of products and companies (aka web presence).
Skilled web designers (by now it had turned into a profession) were able to accomplish effects which exceeded the basic use of HTML as it was originally designed for. Next to the nowadays forgotten
<frame> tag, the
<table> tag had become a common base element for the creation of grid based page layouts filled with images and text.
In their attempts to compose pixel perfect templates, authors started to fill empty table cells with invisible images (spacers), which lead to problems in terms of accessibility. And web authoring tools based on the concept of WYSIWYG were known to produce high amounts of "nested tables", thereby diminishing any chance of converting the textual content into acceptable audio output. The W3C tried to address these trends in the HTML 4.0 Specification:
Authors […] exploited tables and images as a means for laying out pages. The relatively long time it takes for users to upgrade their browsers means that these features will continue to be used for some time. However, since style sheets offer more powerful presentation mechanisms, the World Wide Web Consortium will eventually phase out many of HTML's presentation elements and attributes.
In the year 1999 the Web Content Accessibility Guidelines 1.0 started to distinguish “data tables” from “layout tables” and advised authors to avoid using the latter. Once browsers would support style sheet positioning, “tables should only be used to represent logical relationships among data”.
However, as the same document clarified, the structure of a document itself “is how it is organized logically”. The glossary of “Techniques for Web Content Accessibility Guidelines 1.0” even added, that data tables may not only represent logical relationships between numbers, but also between text and images, thus making it quite unclear on what the distinction between data tables and layout tables is actually based upon. (The often repeated mantra that tables should only be used for tabular data doesn't explain anything)
One year later the W3C created a mailing list, devoted to an appropriate redesign of their own website:
From: Ian Jacobs <firstname.lastname@example.org>
Date: Tue, 04 Jul 2000 19:10:44 -0400
Subject: Re: site comments
[…] Our experiments with trying to design a page that used floats and worked across different browsers on different platforms failed. We debated whether we wanted to use floats and take a stand to promote support for specifications, or to use a table and ensure that the page linearized well (as recommended by the Web Content Accessibility Guidelines ). We chose the table as a practical, not purist solution.
One of the reasons we created this list was to get feedback on how to improve our design, and in particular, how to get rid of the table. […]
More than two additional years later, when common browsers began to support more and more CSS2 features, the W3C finally refurbished its own homepage (see: public announcement) and published a “Tableless layout HOWTO” showing a way to create three columns while getting rid of the table. Now not only tables in connection with spacers or presentational attributes were considered questionable. Suddenly using the table tag for layout purposes, with our without spacers, broke “the meaning of HTML”. From now on the
<table> tag should only be used “to relate columns with rows”. The era of anti-layout-table purism had begun.
The W3C website, 2002: a three column layout table
However, achieving more complex presentations without using tables turned out to be a tedious task. Authors had to struggle with rather non-intuitive declarations like “negative margins”, clearance rules and a rather complex visual formatting model. The
float element - central part of most tableless layout techniques at that time - wasn't designed to be used for complex presentations, thus forcing them to rely on obscure details of its specific implementation (see: Overuse of floats considered harmful, by Mozilla employee David Baron) (Also see: my example). The attempt to define a simple liquid three column layout was dubbed “the search for the holy grail".
The SEO Rapper, 2008: "please don't use tables even though they work fine"
Moreover, “div-soups” began to diminish the benefits HTML was originally offering.
<div> tag, introduced in the HTML 3.0 specification, was meant to be used together with the
class attribute to “represent different kinds of containers, e.g. chapters, section, abstract, or appendix”. HTML 4 added the
<span> tag. Both offered “a generic mechanism for adding structure to documents” without imposing “other presentational idioms on the content”. Authors using them together with CSS were able to “tailor HTML to their own needs and tastes”, without being forced to abuse meaningful (semantic) tags.
This of course limited the machine processability of the documents, as the only information these elements transport is the specific position of data in an hierarchical arrangement, missing the significance Goldfarbs was advertising at the very beginning. Or as Håkon Wium Lie, one of the fathers of CSS, put it in his PhD thesis: “It is possible for CSS to flatten tables into block-level and inline elements, but the intended semantics of the spatial relationship is lost […]”.
The problem here is that layout has meaning. Even so called data tables aren't just arbitrary presentations of abstract data sets and their relations. They present a certain arrangement which enforces certain reading directions. A well designed table is more than a mere block of data. Mendeleev's "periodic table", to use a well known example, allowed to recognize periodic patterns more easily. It revealed "new analogies between elements"; it even allowed to predict new ones. Next to the important role it had in scientific debates, periodic tables became important didactic tools.
While data sets can be presented in myriads of ways, this does not simply imply that one presentation might be as good as another. Whoever tries to present the periodic table of chemical elements in the WWW (not an entirely esoteric scenario for a project that started at CERN) would be well advised to describe the actual properties of the arrangement.
And as stated earlier, the difference between data and layout tables is fuzzier than purists might want to admit. A typical webpage in the 2000s consisted of a sidebar devoted to navigation, a centered content area, a context related advertisement area and an all encapsulating header area. Dividing a webpage into such parts means to structure it (compare: Core Techniques for WCAG 1).
Insisting on no-layout-table purity is a slippery slope. And it obfuscates the underlying problem: The vocabulary a certain structural markup language (a certain Schema, DTD, etc.) provides is usually limited. And what is visually perceivable or thinkable may exceed the semantic expressivity of the given markup language. At the end the day the author of an html document has to describe her meaningful arrangement. And if there is no better vocabulary available, she might just do this in terms of columns and rows. But will that be enough?
6. The HTML table model
The HTML table model, as RFC1942 mentions, evolved “from studies of existing SGML tables models, the treatment of tables in common word processing packages, and looking at a wide range of tabular layout in magazines, books and other paper-based documents.” What was hidden before by the generous use of the
<pre> tag, could now be explicitly marked up. From then on spatial relationships between different text passages and images could be described by using the HTML table model and its corresponding tags. And all these efforts were attempts to narrow the distance between insufficient structural descriptions and the actual richness of relations presented visually.
To analyze the “intended semantics of the spatial relationship” presentable by a plain vanilla HTML table, let us consider a very basic example: a so called data table. Not the periodic table. Something much simpler.
This bipartite graph can be described by using an incidence matrix which could be interpreted, for example, as a typical time schedule, where rows represent hours (19:00, 20:00, 21:00), columns represent days (Monday, Tuesday) and cells represent certain events (a, b, c, d, e, f) occurring at a certain hour of a certain day. (Note: The ordering of the hours and days is not presented in the graph.)
However, looking at the html code of this table, a graphical representation of the corresponding DOM tree (loosely based on the visual language presented in the DOM Level 2 Core Specification) shows a slightly different picture:
Here several problem areas become apart. The
<tr> tags (table rows) enclose the
<td> tags (table data) and
<th> tags (table headers), while the relation between columns and cells is not explicitly marked up. This important structural information is hidden in the ordering, the semantics of the elements and the intended algorithms processing them.
A more explicit description of the relations between the rows and columns is achievable by using the optional
scope attribute of the
<th> tag. But here the role of the very first cell remains unclear. In our rather trivial time schedule this cell can only contain the header of the first row or the header of the first column, not both.
More versatile approaches, like the usage of
axis attributes in connection with hierarchical orderings of headers are debated till today (e.g.: Issue Tracker, ESW Wiki). And as long as the roles of the first column and the first row (and especially the very first cell) of the table are not clearly determined, data-miners as well as screen readers have to rely on heuristics. While extracting specific informations (e.g.: “What events will happen on Tuesday?”, “To which element category does Tellurium belong to?”, “Which part of this website is dedicated to advertisements only?”) is a straight forward task for a non-visual-impaired reader using a grid based layout, extracting data sets out of the imprecise source code is not.
7. ConclusionPresentation isn't a vague reflection of marked up structure. It's the other way round. The main flaw of the HTML table model isn't the often proclaimed misuse (visual layout), but its rather limited descriptive capacities.
While web developers were shifting their practice to tableless design, the CSS2 Specification introduced – rather unnoticed – a CSS table model, which “is based on the HTML 4.0 table model, in which the structure of a table closely parallels the visual layout of the table.” The CSS2 table model consists of tables, captions, rows, row groups, columns, column groups, and cells, while the document language doesn't necessarily has to provide elements that correspond to each of these components. Using the
display property, grouping elements like the generic
<div> element can now be altered to behave like a table cell.
In this rather dubious situation tables are categorized as style properties instead of structural elements, as well as structural elements which can be styled - but shouldn't be used for presentational purposes.
But that's not all. HTML 5 might bring the
datagrid element, while at the same time an XHTML role attribute module is under development. And the current HTML5 draft also promises the introduction of several other new and helpful elements:
The aside element represents a section of a page that consists of content that is tangentially related to the content around the aside element, and which could be considered separate from that content. Such sections are often represented as sidebars in printed typography.
[…] A footer typically contains information about its section such as who wrote it, links to related documents, copyright data, and the like. […] Footers don't necessarily have to appear at the end of a section, though they usually do.
And corresponding to the classical understanding of the structure-presentation relationship, a
footer does not necessarily have to appear underneath a section and the
aside element may be actually not presented aside, but on an entirely different place.
Update: 18.01.2011, the W3C unveiles the HTML5 logo.