| home / programming / css_utopia / chap1 / 1 |    [previous][next] |
|
|
|
Even with the availability of tables as layout mechanisms, designers could not quite attain the detailed level of control over page design that they wanted. Sometimes, for instance, a designer might need a bit more breathing room around one part of a table cell (something for which table design does not allow). This kind of precision was unachievable.
Early on, some designer 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 to contain these transparent images, we could force extra room both vertically and horizontally into tables whose cells were designed to remain in close proximity to one another.
The problem is, 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, however, this technique will often restrict the page to a fixed pixel size, and it clutters the page with images that have no actual meaning for the content of the page. As we'll see later, this severely impacts the ability for users with disabilities to make sense of your site.
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, you can generally 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 HTML-generating tool because you feel you gain more control and understanding if you hand-code everything, then you’ll be familiar with this 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 alright.
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 even 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.
There is 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.
In general (though there are undoubtedly some 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.
| home / programming / css_utopia / chap1 / 1 | [previous][next] |
Legal Notices, Licensing, Reprints, Permissions, Privacy Policy.
Advertise | Newsletters | Shopping | E-mail Offers | Freelance Jobs 
Created: March 27, 2003
Revised: June 10, 2003
URL: http://webreference.com/programming/css_utopia/chap1/1
