Thursday, October 23rd, 2008

display: table, table-cell, table-row, and how we get closer to nicer CSS

Category: CSS

Rachel Andrew has done a great job taking another look at the CSS display ability to use table layouts, that IE 8 has now implemented:

When released, Internet Explorer 8 will support many new values for the CSS display property, including the table-related values: table, table-row, and table-cell—and it’s the last major browser to come on board with this support. This event will mark the end of complex CSS layout techniques, and will be the final nail in the coffin of using HTML tables for layout. Finally, producing table-like grid layouts using CSS will be quick and easy.

The following CSS is used to create the layout below:

  1. #main {
  2.   display: table;
  3.   border-collapse: collapse;
  4. }
  6. #nav {
  7.   display: table-cell;
  8.   width: 180px;
  9.   background-color: #e7dbcd;
  10. }
  12. #extras {
  13.   display: table-cell;
  14.   width: 180px;
  15.   padding-left: 10px;
  16.   border-right: 1px dotted #d7ad7b;
  17. }
  19. #content {
  20.   display: table-cell;
  21.   width: 380px;
  22.   padding-left: 10px;
  23. }

And then quickly brings up what some “anti-table as in HTML table” people may be thinking:

Hang on… Aren’t Tables for Layout Wrong?

Perhaps you’re feeling slightly uncomfortable about the example we’ve just seen—after all, haven’t web standards advocates like myself been insisting for years that you shouldn’t be using tables for layout?

The table element in HTML is a semantic structure: it describes what data is. Therefore, you should only use the table element if the data you are marking up is tabular—for example, a table of financial information. If it would normally be stored in a spreadsheet on your computer, it probably needs marking up as a table in HTML.

The table value of the display property, on the other hand, is simply an indi­cation of how something should look in the browser—it has no semantic meaning. Using a table element for your layout tells a user-agent, “This data is tabular.” Using a bunch of divs that have the display property set to table and table-cell says nothing to that user-agent other than asking it to render them visually in a certain way, if it’s capable of doing so.

Of course, we should also take care not to use display: table; on a bunch of div elements when what we really have is tabular data!

Our simple example above makes our layout behave as if it were a single row table with three cells; it doesn’t take much imagination to realize the potential of this technique for creating complex grid layouts with ease.

Rachel then goes into a lot of great detail on the various options and how it all works out. Of course, although it is fantastic to see this support in IE 8, we will have the constant weight of old browsers keeping us down for awhile to come. Maybe a library could take this in, and convert it for old browsers?

Posted by Dion Almaer at 2:24 am

4 rating from 49 votes


Comments feed TrackBack URI

If you are going to do that you might as well just do it all in tables while your at it.. That is just as “wrong” as using tables..

Comment by V1 — October 23, 2008

This is a world away from the nastiness of table based layout, namely because it doesn’t use tables to achieve the layout. The problem with table layouts is not the CSS it is the semantic structure of the (X)HTML. The new CSS support merely provides a context for the sort of web design we’ve been trying to achieve without resorting to tables in the past.

Comment by kim3er — October 23, 2008

I still think the ‘name'(s) are wrong – I wonder how many webpages in the future will have tabular data laid out using non-semantic markup… I bet more than we’d like…

what’s was wrong with something like:

.container {
layout: border-layout;

.header {
layout: north;


Comment by wukfit — October 23, 2008

…above code should end:

<body class=”container”>
<h1 class=”header”>Header</h1>

…I hope…

Comment by wukfit — October 23, 2008

The display:table-* option is very nice but I don’t know of any way to express colspan and rowspan in CSS. Without them it’s not very useful.

Comment by Menno — October 23, 2008

Maybe I’m not understanding but what makes this superior or easier than putting spans with inline-block inside of a div? (or -moz-inline-box for FF2)

Comment by TNO — October 23, 2008

i fail to see the seemingly now-universal preoccupation with table-less design, especiall when tables are being introduced through the back door. nothing gets better when a bunch of nested divs is declared a table, table rows, and cells through css instead of through html. sure its nice to have that css feature. *important*, however, is a different concept, and clearly implies having some working, manageable css-based way to do layout—which css by design, and even more by implementation, is not able to provide today. css sucks at layout, css sucks in so many details, now announcing with pride and pomp that some version of ie will support laughing horses at some point in the future is a bad joke.

Comment by loveencounterflow — October 23, 2008

agree, it’s funny seeing tables back again even when we’ve been told to steer clear of them.

horses for courses, ;-)

Comment by indiehead — October 23, 2008

Who says tables are back? The point of steering clear of tables in the first place is because its not semantic markup and nested table tags are a bitch to read through and alter not to mention the excess file size it gives.
Of course replacing tables with nested divs/spans is no better when you are just duplicating the very thing you replaced, you just lock yourself back into the same static structure. Laying out a page is as simple as logically looking at the visible DIVisions that make it up and then writing the tag to match it. Wrappers, spacers, floats and so called grids are pointless when you write your css the way it was supposed to be written to complement the tags. Don’t go out of your way to use css to override all of the native behavior of a particular tag.
Disclaimer and reiteration: I’m not against the new functionality available but I do believe its nothing to be excessively hyped up about in the fashion that the article portrays

Comment by TNO — October 23, 2008

[div class=”table”]
[div class=”tr”]
[div class=”td”]

All the benefits of table-based layout without the disadvantages of table-based layout.

Comment by Jordan1 — October 23, 2008

Ultimately the css-based div html does end up looking table-ish doesn’t it? Most designers are too lazy to correctly put more important content first, and then auxiliary content like left navs etc. Thus why not have the table property… It’s what people are doing anyway.

If we’re going down this route I say people just copy and paste the browser table rendering code and replace all instances of ‘table’ with ‘grid’. semantic problem solved.

Comment by ilazarte — October 23, 2008

I agree with TNO regarding the inline-block property. If you need a three column layout, display:inline-block will work in IE6 and IE7 as well as IE8b2.

Comment by WillPeavy — October 23, 2008

@ilazarte :
Changing the name of the tag does not change the semantics, it just changes the name, the underlying meaning is still the same. And no, css based iv html does not look table-ish if you write the content and styles properly

Comment by TNO — October 23, 2008

Using a few other properties it is possible to create a cross-browser friendly solution:

Comment by TJK — October 23, 2008

Semantics refer to both CSS class/ID naming and markup/page structure. Tabular data should always remain in tables, but tables were never meant to be used for layout. CSS wasn’t either, but is evolving to be able to provide layout, while maintaining a semantic (and accessible/machine readable) page structure. Additionally, with CSS control over layout, you will no longer have to edit your HTML to change the placement of page elements that previously existed in tables.

I’m a little disappointed in the W3C’s choice of using table terminology, as it sort of infers a more rigid table-like behavior, which isn’t really the case (e.g. colspan/rowspan), although it is very similar in a lot of ways. The real trouble I have in implementing this today however is the non-support of IE6/7 in particular. Sure, I can update my structure to utilize display: table for some browsers, but I’ll still have to conditionally describe IE layout anyway. Seems redundant to me, and more work for something that doesn’t really buy us much of anything from a user perspective.

Continuing that thought, the CSS3 Grid Positioning Module is quite intriguing (, but again, unless my user base is significantly utilizing browsers that support these features, the choice to evolve my code is a difficult one.

Comment by scottloway — November 12, 2008

Leave a comment

You must be logged in to post a comment.