April 2015, Jesper Tverskov
HTML tables are for data and should only be used for design as an exception to the rule. In the following, I explain why tables for design can be necessary and give examples from the friendlytest website. Even nested tables are legitimate if there is no good alternative.
In early web design, HTML tables were used to make the basic layout of web pages often nesting tables inside tables in very many levels. This gave us source code that could be difficult to maintain.
The main reason for the misuse of tables is interesting. Tables are simply very easy to understand. You do not have to learn how to make even complex solutions. A few experiments and you can solve almost any problem.
Little by little, other elements li5ke "div" styled with CSS have replaced tables for basic layout. With basic layout we normaly think of the overall structure of a webpage into areas like columns, header and footer.
Table-less layout is most often more efficient than table-layout, but it takes a lot of advanced CSS, and that is something you must learn. In the beginning, for any CSS solution of any complexity, you must search the web for hints and tricks to help you out not using tables.
It is fair to say that tables should only be used for design, if a reasonable CSS based solution does not exist. With reasonable I mean that the solution must not be so far out that it borders the realm of CSS hacking or be so complex that a table is much easier. In addition, the solution must be supported in most browsers in use today.
Tables are not only easy to use; they also have a couple of unique qualities. Unique in the sense that they don't exist for other elements or are a little difficult to reproduce except for several new options in CSS3 not yet supported in many browsers.
By default, the size of the table adapts to the size of the content. If the content gets bigger, the table gets bigger, if the content shrinks the table shrinks. In addition, the table cell by default align content vertically in the middle.
The most important quality of a table and the reason why it is often indispensable for layout, is the ability of one table cell in a row to get higher because the row gets higher: The height of all cells in a row adjust to the highest cell in the row.
CSS has a display property often used with values like "block" or "none". But we also have a handful of table related values like "table", "table-row" and "table-cell", that can turn elements like "div" into behaving like a table in the browser.
In my opinion, these display values should not be used as a last resort to get rid of the very last table of design.
For illustration, here is a table made with div elements:
A table made of nested div elements and CSS.
If we want table behavior in HTML, use the table element. That is why it is there. If you want table behavior, it is probably because data has some relationships important enough to come alive using a table. Your table might be far from a clear cut data table but evan vague relations can justify a table.
Why do we have values like “table”, “table-row” and “table-cell” for the display proterty, if they are not to be used? Because CSS was meant to be used not just by HTML and XHTML, where we have table markup understood by the browsers, but by XML based markup languages in general when we want to visualise them in browsers.
For many reasons, displaying anything but HTML and XHTML in browsers never took off, except for some specialized markup languages like SVG and MathML. The main reason is that CSS isn't powerful enough. It lacks transformation capabilities.
When we want to display data stored in some general XML based vocablulary, we most often want a subset of the data, some selection. We want to group and sort data, we want to add something, etc. That is, we need programming like XSLT (eXtended Stylesheet Transformation) or some traditionel programming language, before we add CSS. And with all that programming in place we can just as well transform our XML markup to HTML or to XHTML.
As always, we might have exceptions to the rule of not using the table related display property values. Even if we only have these display values by chance, we can just as well use them, if we really need them. There might be situations, when we want a solution to toggle between table-like behaveior and just nested "divs" elements. By using display properties, we only need to change a property value programatically. We can do the same without the property values but it takes more advanced DOM scripting.
A data table is basically just a clever way to present data to make the data easier to understand. This can be the most magic if strong relationships exist in the data. But even if only vaque relations exist, a table can be of much help. Just like an image can say more than many words. There is no clear definition of what makes a table a data table and what makes a table a design table and it is no big deal to tell them apart. When ever a table will make a web page better, use one.
We use tables for multiple choice questions to have an image to the left and the question and answer options to the right. We want a robust solution that works also without images, with other media files, and when answer options are reduced from 5 to 2. One could argue that these tables are data tables. Just because we have reduced a friendly test to the test itself without distractions, for the sake of accessibility and usability, the tables are still data tables. We could add column headers, and make them look exactly like a tradtionel data table.
But nested inside those tables, we use a table to replace list elements in order to make the web page look better if extreme zoom, a very low resolution or a narrow view port in the browser window is used. This is valid markup and the browsers have been so used to nested tables in the past, that it is almost impossible to get them wrong.
The answer options of a multiple choice question is not looking that good if one or more options have linebreaks and word wrapping. By using a HTML table element, a linebreak still tilts the layout but it is less damaging.
Let us take a multiple choice answer option from the "Oxford" test that looks like the following:
Balliol College Dining Hall
If the user zooms 200% or more or use very low screen resolution or a narrow browser window, a linebreak like the following is not good enough:
Below I use the "definition list" element and float property. Still not exactly what we want:
Using a HTML table element, one table row and two table cells, the perfect solution is easy to achieve. It is default behaviour of a table:
In the image below we see the answer option with linebreak in context. Each option is a table row with one cell for the radio button and one cell for the answer text.
If an alternative solution using list elements exists, and if it is almost as straight forward as using the default behaviour of a table, we will be happy to use that alternative and get rid of the nested tables.
Follow the link for the full Oxford test. The "slideshow" mode simply uses a number instead of a radio button and each option is a link. The slideshow solution is one big JavaScipt and doesn't work for screen readers. If you have a free account you can take the test also in "document" mode, a nice alternative for all users.