Use the table-layout CSS property to speed up table rendering
A rarely used CSS property that can be very useful given the right circumstances is the table-layout property. It has great rendering speed benefit when used properly. Obviously this will only apply to HTML <table>s, which I know none of you would EVER overuse. Tables are not totally evil, they have their proper implementations and their really, really bad ones. OK, on to the code:
/* Set table to "fixed" (fastest render) layout */
.fixed_table {
table-layout: fixed;
}
/* Set table to "auto" (best fit) layout. This is the default */
.auto_table {
table-layout: auto;
}
Or alternatively in JavaScript:
$('elementID').style.tableLayout = "fixed";
When you want to use table-layout: fixed
So how fixed table layout works is that the browser looks at the first row of the table and determines how to render the table based on the table width and the columns but NOT on the content of the columns. This allows large tables to be rendered faster but risks the table not displaying “optimally”. The best place to use table-layout: fixed is on larger tables (probably > 50 rows) and fairly uniform table cells (as in the cells should evenly divide the table). The benefit can be significant when the browser does not have to calculate the optimal width of each table cell.
When you want to keep the default style table-layout: auto
There is almost no benefit to setting a small table totable-layout: fixed. Furthermore, if the cell content varies greatly in length, your table may look really funky and different browsers may display your table in quite odd ways. Let me show you what I mean. Here is a quick example:
| Header 1 | Reallyreallyreallyreally looooong header | Header 3 |
|---|---|---|
| Reallyyyyyyyyyy Looooooong cell conteeeent | short | Normal cell content |
| short | ReallyyyyyyyyyyLooooooong cell conteeeent | Normal cell content |
| Header 1 | Reallyreallyreallyreally looooong header | Header 3 |
|---|---|---|
| ReallyyyyyyyyyyLooooooong cell conteeeent | short | Normal cell content |
| short | Reallyyyyyyyyyy Looooooong cell conteeeent | Normal cell content |
So don’t mess with table-layout: auto in these circumstances because it is just too unreliable. The harsh reality here with the automatic table layout is that the:
algorithm is sometimes slow since it needs to access all the content in the table before determining the final layout
This is why nesting or otherwise overusing <table>s is a bad idea.
For those interested, here is the official spec from the W3C. Have you ever used the table-layout CSS property? Was it useful and what was the result? Let’s hear it!
Popularity: 21% [?]
14 Responses so far
Trackbacks
- purrl.net |** urls that purr **|
- links for 2008-02-20 | lutsr
- Velocizzare il rendering delle tabelle con la proprietà table-layout : cssblog.it
- CSS-FAQ » Blog Archive » Speeding up table rendering in CSS
- » CSS-Tips: table-layout — cne _LOG Archiv
- User First Web » links for 2008-03-15
Leave a reply



Awesome post! Thanks for pointing out that tables are not always evil — they still have their place.
Thanks, David. I think it does need to be stressed more that tables are not bad. I think we web developers are pre-judgmental this way because we see so many bad implementations vis-a-vis frontpage etc.
A bad coder could overuse divs or any other element and really it comes down to everything in balance.
What do you think about using a single fixed table to hold the layout of the page? Versus the alternative shown here:
http://www.positioniseverything.net/articles/onetruelayout
The onetruelayout div method seems hacky to get everything right (col height, etc).
@rreed:
This might seem like a political sort of answer: it mostly depends on your situation.
Let me explain: I totally believe in fluid and semantic layouts, and if it were just me designing a new site, I have and will continue to use a method like the onetruelayout.
Here’s the problem: it is not as simple as using a table, and most applications require much more maintenance and coding time than the initial deployment. Since the onetruelayout method gets preogressively harder to maintain and upgrade as you increase the size and diversity of your team, it’s benefits would not be worth it when used by a team of any more than 3 really good coders.
So the conclusion here is that if you are building something for yourself, use onetruelayout. It is better and you will learn more using it. If you are on a bigger team, use the simplest layout possible because the end benefit will be greater that way.
Does that answer your question to your satisfaction?
table-layout is one of those CSS properties which is often overlooked but definitely has it’s uses. I’ve also seen it used when an image has been placed in a table cell but the table has been rendering (in some browsers) the width of the alt text before the image has a chance to load so using this method can also have other uses.
@Dave:
That makes sense. I wonder if there is a way to prevent the table from using the width of the alt text while keeping the “optimal” cell width calculations of table-layout: auto…
Well coded
Very nice :) btw very good tips i will use them. Some of them i did not knew.