Table Based Web Layout vs. CSS Positioning

February 9th, 2005

I reviewed an excellent book on this topic recently that should be of interest to anyone who finds this blog post by searching regarding table based design or CSS. The book is the Zen of CSS Design.

When I learned HTML 3 a few years back, I enjoyed the power to publish content to the web where people from all over the world could access it easily. But as the web projects I developed became larger, I wished for a way to control design elements in a more centralized way.

In this pre-CSS world, if text links throughout the site were not visible enough to attract users’ attention, each link or at least the body element on each page would need to be edited to change the behavior and display of the text links throughout the site. In addition, the most frustrating aspect of design with HTML alone was being forced to use tables, designed to organize tabular data, to control the visual presentation of documents. Spacing needed to be done with images, and the code did not make sense in a text browser.

When I was introduced to Cascading Style Sheets (CSS) in its first incarnation, CSS was limited largely to the control of text and link behaviors. Even in its nascent form, it showed a great deal of potential to save repetitive work for the web designer. The many benefits of design with CSS include a lower page weight and faster load time, greater accessibility to text browsers and handheld devices, greater control over type display, cleaner (X)HTML code that often results in better search engine results.

Now that I am free of table based design, I have no desire to return. Of course, I still think tables should be used for tabular data like calendars and well, tables. The chief arguments against CSS design for visual control are that it is difficult to learn (true, but it is well worth the effort) and that it requires hacks in order to render equally well in current and older browsers. These are valid reasons to think twice before learning CSS, but not valid reasons to avoid using it if you already have mastered its intricacies. In fact, as skill level with CSS increases, it becomes almost imperative to use it rather than tables.

When I started using CSS 2.1 for document layout, I made the mistake of mostly substituting page divisions (

tags) for table cells. Though this increased the accessibility of the pages I designed and enabled more ease in maintenance and making site wide changes, it merely replaced one sort of cluttered code with another less cluttered code. As my comfort level increases, I have found ways to style natural page elements (semantic code) rather than introducing page divisions. So as knowledge increases, code can become increasingly simple, semantic, and accessible. As this takes place CSS begins to tower over tables as a visual design tool in its flexibility and power.

The next frontier that I must take my small design firm through is the mastery of accessibility to audio interpreters, such as screen readers, handheld devices, and full Section 508 compliance as mandated by law. Imagine a screen reader parsing a table based web design, “table data, image, table data, welcome to this web site, table row, table data, image, table”. You get the point. Within a mature understanding of CSS and semantic code, these standards can be gracefully implemented without a loss of visual appeal and without an increased page load. This is the future of web design, a virtual world with as few barriers as possible.