HTML, CSS and Tables: The Beauty of Data

In the old days of Web design, a table was styled with visual elements and attributes--markup that defined how something looks rather than what it is. As CSS was not yet defined, and browsers rendered attributes differently, we were forced to create lines, margins and paddings with "spacer" images--transparent GIFs that allowed us to set a width and height to their parent elements and allow the background colour to shine through.

This resulted in huge tables, both concerning line count and file size, and changes had to be repeated in each document. Our example table using spacer GIFs turns out to be almost 10KB and 215 lines of HTML markup.

When the browsers of the third generation mercifully went the way of the Dodo bird, we were able to use HTML properties more cleverly to avoid all the overhead of spacer images. Padding and spacing together with a clever use of background colour allowed us to cut down our table to become roughly 2KB and 35 lines of markup. Yet we still had to replicate the color information and padding for each table and each table element.

With the 5th (and partly 4th) generation of MSIE coming out, we were able to use CSS properly for the first time. CSS allows us to keep the visual presentation information in a single file that gets applied to all the HTML documents. Changes can be applied a lot easier that way and we can keep the HTML free of presentational elements and attributes.

Sadly enough, however, a lot of developers didn't grasp that these newer browsers also support the aforementioned "new" table elements and attributes, and simulated these by applying classes to each element. These tables suffering from "classitis" failed miserably in conveying the flexibility of CSS. Classes became the new font tags. This is still the case for a lot of WYSIWYG tools these days. Our example table suffering from classitis amounts to about 700 bytes of CSS and 1.3K of HTML data in 44 lines.