Understand the Table Controversy

Have you ever used a spreadsheet program? If so, you have a rough idea of what tables are and how they normally look. Tables were developed and added to the HTML standard in the early 1990s to provide a way to display structured information, such as in a spreadsheet. Before that time there was no good way to display columns of data in an HTML document; because HTML originally was devised for scientific and academic material, this presented a problem. The introduction of tables not only solved this problem, but also provided a solution to another, as yet undiscovered, problem.

The Origins of the Table Controversy

When the Internet was in its infancy, presentation and design weren’t very problematic, but graphical browsers changed all that. However, basic HTML did not provide the tools for control that designers were used to. In fact, a Web designer was completely at the mercy of browser, system, and HTML limitations when it came to doing Web page layouts. Placement and appearance of text and graphics were not absolute, but static. A layout that looked good on a designer’s machine might be totally transformed on someone else’s system.

Then Web authors discovered tables. By putting text, graphics, and other content inside table cells, designers could take advantage of a table’s structure to “force” a browser to stay within a particular layout. Tables certainly did not solve all the difficulties Web developers faced, but they represented a great improvement. However, tables were not designed with layout in mind. They were created to organize “tabular” data. In other words, when Web designers use tables to create a layout, they are applying HTML markup in a way that was never intended. The issue isn’t merely that the leaders in the Web community are zealous to keep HTML pure. Rather, it is because using tables this way creates accessibility problems for people who must use alternative or nonvisual browsers.

The Accessibility Issue

If a visually impaired person tries to access your site using an aural (audio) browser and you have used tables to create your visual layout, the browser will probably have difficulty deciphering your code. Nonvisual browsers depend on HTML code being applied according to standard, not in whatever manner a designer finds useful. That is why there is such a strong emphasis on learning to write standards-compliant code in the Web community. It’s about making your pages available to everybody. However, even though the overall trend in the Web is toward using Cascading Style Sheets (CSS)—and ultimately XSL or Extensible Stylesheet Language—tables still are the layout tool of choice for most Web authors. If you’re not convinced, just go to virtually any major Web site and view the source code. More often than not, you will find that tables figure significantly in the design. Despite accessibility issues, clearly many Webmasters are reluctant to abandon tables. Why?

The Browser Support Issue

Tables remain the design tool of choice largely because they enable designers to maintain a certain degree of control and consistency in their Web layouts. Because the browsers are inconsistent in their support of Cascading Style Sheets, layout and page design can vary radically between different browsers, and even between different versions of the same browser. This necessitates the creation of multiple style sheets that are custom designed for the quirks of all the different browsers and versions. Unfortunately, the CSS positioning (layout) properties are among the most poorly supported. Thus, a design that depends solely on CSS is likely to be very unstable. On the other hand, tables provide a stable and consistent means of structuring a page. Therefore, they remain popular and probably will continue to be so until browser manufacturers offer more consistent support for CSS.