Online battles between those who use tables for layout and those who stick to structural markup will rage for a long time because old habits are hard to get rid of. For most people, at least. The "old habits" I'm referring to are tables and their use in web design. Aside from the fact that tables have been wrongfully used they are also slow. We're going to review how slow they are and why.
So What's Wrong With Tables?
They are slow. I bet you can also nest divs to the point where they will be slower than tables, but it takes work to accomplish it. It takes a browser much longer to calculate dimensions of a table. It has to load the entire table, analyze content of each cell, readjust column widths based on the content. If you happen to have nested tables (as most people do) these calculations are performed on a nested table, than the browser backs out and does these calculations for the parent table and so forth. Just that you get a glimpse of this complexity I'll allow myself to copy and past the "algorithm" from the specs:
- Calculate the minimum content width (MCW) of each cell: the formatted content may span any number of lines but may not overflow the cell box. If the specified 'width' (W) of the cell is greater than MCW, W is the minimum cell width. A value of 'auto' means that MCW is the minimum cell width. Also, calculate the "maximum" cell width of each cell: formatting then content without breaking lines other than where explicit line breaks occur.
- For each column, determine a maximum and minimum column width from the cells that span only that column. The minimum is that required by the cell with the largest minimum cell width (or the column 'width', whichever is larger). The maximum is that required by the cell with the largest maximum cell width (or the column 'width', whichever is larger).
- For each cell that spans more than one column, increase the minimum widths of the columns it spans so that together, they are at least as wide as the cell. Do the same for the maximum widths. If possible, widen all spanned columns by approximately the same amount.
I re-read this several times before I could grasp the concept. Try applying this to nested tables. All this says the width and height of cells and rows is not guaranteed to be what you expect them to be.
Turbo Charge Tables
Deep inside the CSS spec lies a property which can miraculously speed up table rendering by a factor of 100 or so. This property is table-layout. The idea is relatively simple: tell the browser how wide each column is. The browser would have to stick to the measurements and clip content if need be. For this to happen you have to apply the following style to a table:
<table style="table-layout:fixed;"... >
With table-layout set to fixed a browser computes column widths as follows (the order is important):
- By using information in the
width property for the col or colGroup element.
- By using information in the
width property for the td elements in the first row.
- By dividing the table columns equally, regardless of the size of the content.
If the content of a cell exceeds the fixed width of the column, the content is wrapped or, if wrapping is not possible, it is clipped. Use the CSS overflow property to specify how content clipping should be handled.
What does this give us? Faster rendering. The browser doesn't have to parse an entire table. Only the first row would suffice. This alone removes a lot of ambiguity. The CSS spec has this much to say about it:
In this manner, the user agent can begin to lay out the table once the entire first row has been received. Cells in subsequent rows do not affect column widths. Any cell that has content that overflows uses the 'overflow' property to determine whether to clip the overflow content.
That's pretty darn simple conflict resolution. What about cell height? Again, help the browser by setting the row height. The example below (via MSDN) sums it all up:
<table style="table-layout:fixed;" width="600px">
<col width="100px">
<col width="300px">
<col width="200px">
<tr height="20px">
<td>...<td>
<td>...<td>
<td>...<td>
<tr>
:
<table>
Wrap-Up
I always advocate semantic markup over table layouts, but this time around I wanted to simply suggest how to give tables a boost. Consider this a patch. It doesn't change the pretext that tables have to go. We should be using them for tabular data, not page layouts. They are not presentational elements per se. I encourage you to start making the transition.
Further Reading
Tables My Ass by htmldog
An Objective Look at Table Based vs. CSS Based Design by Andy Budd
Gasp! Tables! by Dave Shea
