Insight
Why Most—But Not All—Tables Are Bad
By Rachel Andrew and Dan Shafer
Excerpted from HTML Utopia: Designing Without Tables Using CSS, 2nd Edition (SitePoint)
Dateline: July 26, 2006
Discuss this in the Web design forum
Almost as soon as the Web became popularized by the emergence of early
graphical Web browsers (such as the wildly popular Netscape Navigator), the designers
of early Web sites became aware of a problem. The method by which the
Web browser displayed information stored in HTML files was not within the designers’
control. No, it was primarily the users who were in charge of how the
Web pages they visited would appear on their systems.
While there were many, including myself, who thought this was A Good Thing,
designers were beside themselves with concern. From their perspective, this constituted
a fundamental flaw. “Users don’t know anything about good design,”
they argued. If the designers couldn’t control with great accuracy things like colors,
fonts, and the precise, pixel-level positioning of every design element on the Web
page, their creations could easily end up as ugly travesties in users’ browsers.
Most designers, accustomed to print and other fixed layouts that afforded them
complete control over what the user saw, found ways to bend the Web to their
will.
Lest I incur the ire of every designer reading this, let me hasten to add that
I don’t think this was A Bad Thing. It is certainly the case that designers know
more about how content should be displayed for users than do the users themselves.
Things like spacing, color combinations, and other design elements affect
readability and usability. My point has much less to do with who should have
been in charge, than it does with the actions to which designers were more or
less forced to resort in order to achieve at least some measure of control.
Soon, expert designers discovered that they could use tables to gain significant
control over the presentation of content to users. By laying out tables within
tables within tables, they could position quite precisely any design element that
could be contained within a table cell. And that encompassed almost everything.
The first desktop publishing-style Web page design tool, NetObjects Fusion, enabled
designers to lay out pages with a high degree of precision. It generated
complex, table-based HTML, which resulted in Web pages that were as close as
possible to the designer’s original vision.
We never looked back.
But tables weren’t intended to be used as layout tools, so while they were effective,
they were also horribly inefficient. We’ll explore some of the shortcomings and
disadvantages of using tables for layout tasks a little later; for now, just know that everyone, including the designers who used the techniques, understood
pretty well how clumsy a solution they really were.
After a brief series of skirmishes at the beginning of the Web’s development, the
question of who should control the overall appearance of a page or site ended
with the designers as victors. Users, after all, care more about usability, accessibility,
and convenience than the nitty-gritty details of design techniques.
Yet designers found themselves hard-pressed to identify very good, standardscompliant
ways to provide their customers—and their customers’ users—with
great designs that were also effective and efficient. Thus, they were forced to rely
largely on tables.
However, as time passed and the use of tables to lay out Web pages became increasingly
complex, even the design community became uneasy. Maintaining a
Web page that consists of a half-dozen or more deeply intertwined tables is a
nightmare. Most designers prefer not to deal with code—even simple HTML
markup—at such a level of detail.
Into the breach stepped the World Wide Web Consortium, better known as the
W3C a body founded by Tim Berners-Lee to oversee the technical growth of
the Web. They saw that separating the content of a site from its presentation (or
appearance) would be the most logical solution. This would enable content experts—writers, artists, photographers, and programmers—to provide the “stuff”
that people come to a site to see, read, or experience. It would also free the design
experts—artists, graphic designers, and typographers—to determine a site’s aesthetics
independently of its content.
The result was CSS.
Why is the table not suited to being a design mechanism? There are numerous
reasons, but the ones we’re most concerned with in this context are:
- They result in load times that are longer than necessary.
- They encourage the use of inefficient “placeholder graphics” that further slow
performance.
- Their maintenance can be a nightmare in which even minor changes break
the entire layout.
- They can cause the page to become inaccessible to those who are not using a
graphical Web browser.
Tables Mean Long Load Times
Most people don’t know that Web browsers are deliberately designed to ensure
that each table downloads as a single entity. None of the material that’s contained
in a table will be displayed until all the contents of that table are downloaded to
the client machine and available for display (Cascading Style Sheets Level 2 includes a property called table-layout that alters this
behavior, with several important caveats).
When the original, intended purpose of tables is taken into account, this makes
sense. Tables were designed to display... well, tables of data. Each cell contained
a value that was being compared to, or related with, the values of other cells in
the table. Isolated bits of data appearing quasi-randomly would not do; the table
was a single, integrated entity.
When designers began to rely on tables to contain all or most of the content of
a Web page, they were also saddled with the consequences of this design decision.
In addition to the apparent delay that many users experience as a result of tables
displaying all at once, the sheer volume of HTML code that’s required to create
Web page layouts with nested tables can also add load time due to the increased
page size. Table-based layouts almost certainly account for more user concern
over long page-load times than any other single factor.
Avoiding this significant load time would obviously be A Good Thing.
Use of Transparent Images Slows us Down
Even when using tables as layout mechanisms, designers could not quite attain
the detailed level of control they wanted over page design. Sometimes, for instance,
a designer might need a bit more breathing room around one part of a table
cell—something for which tables do not allow. This kind of precision was unachievable.
Early on, someone came up with the notion of creating a transparent.gif image
file—a tiny GIF image that had no visible content. By creating table cells that
contained these transparent images, we could force extra vertical and horizontal
“space” into tables whose cells were designed to remain in close proximity to one
another.
The problem is that, given a table with dozens (or even hundreds) of these images,
and depending on a variety of other factors, the performance impact of transparent
GIFs on a Web page can be significant. More importantly, though, this technique
often restricts the page to a fixed pixel size, and clutters the page with images
that are irrelevant to the meaning of the page content. This severely impacts the
ability of users with disabilities to make sense of table-based sites, as we’ll see
later.
Maintaining Tables is a Nightmare
The third reason why most tables are bad is that maintaining a complex array of
deeply nested tables is a nightmare. If you use tools such as Macromedia
Dreamweaver or Adobe GoLive to manage your sites and their designs, generally
you can ignore the messiness of the nested tables that make the design possible.
But even these tools are not foolproof, and when they “mess up” (to use a highly
technical term), amending the unsightly pages they create can be quite a challenge.
If you’re like most designers, and you wouldn’t be caught dead using an HTMLgenerating
tool because you feel you gain more control and understanding if you
hand-code everything, then you’ll be familiar with the maintenance problem.
The difficulty arises because, by necessity, tables have a fairly complex set of
tags—even if they aren’t embedded within other tables. And when we have nested
tables, well, we’ve got a clear case of the uglies, all right.
The situation is further complicated by the fact that, unlike programming editors,
HTML editors generally do not force or support the clean indentation of code.
So, finding the start and end points for a given table, row, or cell turns out to be
what software folks call a “non-trivial task.” While it’s true that a competent
HTML coder or designer could make this problem more tractable, it’s never really
solvable, no matter what we do.
Tables Cause Accessibility Issues
The fourth reason why tables are bad lies in the way non-graphical browsers—such
as the screen readers used by many visually impaired users—read an HTML
document. When a text-only device reads the content of a site, it starts at the
top and works down the page line by line. When it comes to a table, it starts at
the first (top-left) cell, then continues along the top row, then moves to the
second row, and so on. In the case of a table that’s used correctly, for tabular
data, this is rarely a problem. However, where nested tables have been used to
display chunks of text in the desired layout, that content can become nonsensical
when read in this manner.
When it’s Okay to Use a Table
There’s one notable exception to the cardinal rule that Tables Are A Bad Thing.
If you have tabular data, and the appearance of that data is less important than
its appropriate display in connection with other portions of the same data set,
then a table is in order. If you have information that would best be displayed in
a spreadsheet such as Excel, you have tabular data.
In general (though, undoubtedly, there are exceptions to this rule as well), this
means that the use of tables should be confined to the presentation of numeric
or textual data, not graphics, multimedia data types, forms, or any other interactive
user interface components.
|
