A Web Designer’s Confession
In this new century, Web designers and developers have been on a crusade to standardize the rendering of webpages across platforms and browsers so that all comers experience the Web consistently. It is a noble ideal, and it has been a pitched battle with the continuing prevalence of Microsoft’s Internet Explorer 6 retarding the adoption of these standards. But with the now waning dominance of IE, these standards are winning the day, making life much easier for designers like myself, and forcing even Microsoft to join ranks with the latest incarnation of its Web browser, albeit half a decade late. (IE6 has become virtually a four-letter word amongst designers and developers.) For the end-user, this standardization means that webpages can be more attractive and interactive, both because more reliable tools are available to the developer and because less time needs be spent hacking code. However, though I am an enthusiastic supporter of these standards, there is one that I continue to be guilty of breaking, and for good reason. So, penitently, here’s my confession.
Tables for Tables
One of the cardinal rules of these emerging Web standards is that the right tools be used for their intended purpose. HTML is for structure and content. CSS is for style. Before the proliferation of CSS support across browsers, Web designers were forced to use all manner of HTML trickery to achieve the desired result, including the use of HTML tables for page layout. But, as the evangelists of standards are quick to point out, tables aren’t intended for layout, but for tabular data. So today, the use of tables for layout is seriously frowned upon. Unfortunately, the current state of CSS and HTML support includes no adequate means of creating columns without tables, and as a result, designers have resorted to endless tweaks and contortions to create columns with CSS, all for the sake of avoiding the dreaded <table>, <tr>, and <td> tags. As is their nature, designers are just as averse to ugly code as to ugly design, and table tags litter code with an abundance of tags, which by necessity are often spread across multiple files such as header, footer, and content templates. It is far from an ideal situation. Nonetheless, the fact remains that tables are far more adept at creating columns than any of the available alternatives.
Tables for Columns
Table columns have two distinct advantages. First, each column in a table naturally expands vertically in sync with each other. For designs that require horizontal alignment along the base of one or more columns, this natural behavior is a must. It can be replicated with CSS to some extent by “wrapping DIVs”, but only if you know that one column will always be the longest, and only with mixed results. So, for some webpage layouts, tableless code is a real option, but for others, it is a costly goal. Secondly, with the standard horizontal orientation of most computer screens, centering webpage designs is desirable in most cases. Again we find that doing so with columns seriously limits the designer’s control while tables can be centered effortlessly without loss. Using DIVs and CSS with “absolute positioning” preserves the designers control, but then fluid centering is lost. Tables, in contrast, make it easy to attach design elements to the table that effectively anchors the desired center alignment.
Because of the inherent current limitations of HTML4/CSS2 in tandem with the principled objection to using tables for layout, if you look closely, you’ll notice a confluence of design styles across a broad range of websites. It is the natural result of operating within a certain set of rules. The tools will, to some extent, always constrain the end result. Now, it should be said, many of these tableless designs are breathtaking. The excellent WebDesignerWall reflects this approach at its best, while also exemplifying that confluence of styles I mentioned. One might ask, if such results can be achieved without tables, why not join the bandwagon? It’s a good question. For now, my answer is twofold. Some designs simply are not as amenable to tableless code. And, because of the greater flexibility and consistency of table columns, they better serve clients’ needs, whose web editors and authors are not often familiar with the idiosyncrasies of the underlying HTML.
The Future Looks Bright
This is the good news. Though their official ratification is a long ways off, HTML5 and CSS3 are already being implemented in today’s leading browsers, namely Safari, Firefox, and Opera. Even Microsoft appears to be making an honest effort to tag along. The extent to which HTML5 addresses columns and a litany of additional shortcomings in the current specification is truly exciting. Of course, as long as IE6 remains prevalent, the audience of any particular webpage will have to be considered before using these new and sharper tools. Finally, it’s also worth admitting that maybe the real problem is that I haven’t truly mastered the potential of the current standard. Perhaps so. And desirous as I am to be the author of clean and simple code, I’ll keep trying.
Postscript. Now, some six years later, true columnar display is becoming a reality with the Flexbox model.