Three simple reasons why tables for layout are bad

By Martin / (X)HTML & CSS, Musings / Sunday August 2nd, 2009 / No comments

Using tables for layout is bad, as is repeated over and over again. However, it is often hard to find definitive explainations on the disadvantages of coding in that manner. Well, here are three really simple reasons why, in my opinion, tables are not a good thing to use for the structure of web pages.

1. Accessibility and semantics

This is a really obvious one. HTML was designed to be a descriptive, or semantically rich, language, where every different tag has a definite meaning, understandable in any context. In this manner, header tags are supposed to be used to show headers, paragraph tags to delimit paragraphs, and table stuctures to represent tabular data, thus allowing any user agent, be it human or electronic (i.e. search engines, or people using screen readers) to understand a page of HTML code, even if it was not possible to apply styling. If you use a tag out of its correct context, however, the meaning and structure of the page becomes muddy and less clear, and thus harder to interpret. For this reason, it is espeically hard for search engines to understand table-based layouts, as the natural flow of the code is lost in the segmentation necessary to present complex designs through tables (thus, the importance of semantics in SEO). For non-visual agents, and also for braille output devices, too, a strangely marked-up page (headers inside table data cells?) leads them to present the data in a confusing and illogical way. However, using CSS in the proper manner, to separate the structure of the page from the presentation, it is possible to maintain a logical flow while still presenting a multi-sectioned layout, and render a page logical to read, no matter what is used.

2. Flexibility

Layouts designed using tables are almost ubiquitously very rigid - once a layout decision is made (e.g. "this column will be on the left") and coded, it is almost impossible to revise in the future. However, what if, suddenly, your designer decides that the column should be on the right instead? You'd have to go round, frustratingly trying to pick apart the complicated markup that tables require. However, with CSS, it is possible to markup elements in any order you like, and only then use CSS - a separate entity - to layout the page. Thereby, complete flexibility can be maintained - any changes in layout can immediately be implemented requiring only modifications to the CSS file. This is the principal is the separation of content and presentation. Note: for an interesting implementation have a look at http://www.csszengarden.com/.

3. Speed

In general, tables are very slow to render, especially nested tables, as since tables were meant for simple, two-dimensional gridded data they complexity for the renderer quickly builds when multiple levels, complex column grouping and other methods necessary for layout tables are required. Also, because of the way tables are defined, renders have to wait until the entire table loads before beginning calculations - making the apparent load time for a table even longer. As opposed to this, CSS rules can be applied very fast in a linear fashion, and elements can be rendered as soon as the load, leading to significantly faster websites. In a related issue, if tables are used for layout the presentational data needs to be loaded every time the vistor changes pages, slowing things down, while CSS definitions only have to be fetched once, and can then be cached.

Tables for tabular data

As a note, it is important to remember that it is not wrong to use tables for tabular data - that is their intended purpose, and trying to use some "div" hack to achieve a table is as bad as using tables for layout.