meyerweb.com

Skip to: site navigation/presentation
Skip to: Thoughts From Eric

CSS Gridlock

I mentioned in my post that the only CSS grid layout capability is styled tables.  Then I said that the only “pure CSS” grid layout approach being to apply table-related display values to non-table elements.  In one sense, I said the same thing twice, but in another sense, I contradicted myself.  When I read the post again, I decided that a little clarification was in order.

So let’s say that you have a deep burning desire to create a grid-based layout without using any table markup.  Suppose this layout is based on a 3×3 concept, where the pieces all need to have their horizontal and vertical edge line up with each other.  To do that, you’d need styles and markup like the following:

<div id="layout">
 <div class="hgroup">
  <div class="cell">...content...</div>
  <div class="cell">...content...</div>
  <div class="cell">...content...</div>
 </div>
 <div class="hgroup">
  <div class="cell">...content...</div>
  <div class="cell">...content...</div>
  <div class="cell">...content...</div>
 </div>
 <div class="hgroup">
  <div class="cell">...content...</div>
  <div class="cell">...content...</div>
  <div class="cell">...content...</div>
 </div>
</div>

Then, to that markup, you’d apply the following styles:

div#layout {display: table;}
div.hgroup {display: table-row;}
div.cell {display: table-cell;}

So there you go: a grid layout that uses absolutely no table markup by applying table display roles to other elements.  And the point is…?

Frankly, I don’t think there is one.  Because let’s be honest, given a choice between the markup in that previous example and this next one, I think the next one is not only easier to read, but it’s lighter in markup weight.

<table id="layout">
 <tr>
  <td>...content...</td>
  <td>...content...</td>
  <td>...content...</td>
 </tr>
 <tr>
  <td>...content...</td>
  <td>...content...</td>
  <td>...content...</td>
 </tr>
 <tr>
  <td>...content...</td>
  <td>...content...</td>
  <td>...content...</td>
 </tr>
</table>

Not to mention the table will work in IE/Win, whereas the “pure CSS” version I detailed won’t.  That kind of puts a damper on any enthusiasm I might have summoned for it.

In CSS terms, the reason a table works the way it does is that the browser itself applies the following rules from somewhere deep within its codebase:

table {display: table;}
tr {display: table-row;}
td {display: table-cell;}

I know, tables have existed for longer than CSS, but my point isn’t that CSS makes tables possible.  What I’m saying is that that’s the CSS way of describing a table and how it functions.  If you want elements that effectively bind together and affect each other’s height and width, then table-related display values are the only game in CSS Town.

Is that enough?  It doesn’t feel like it to me, but on the other hand, any grid-layout system would have to do basically the same things.  For example, suppose we invented a set of properties and values to describe a grid layout.  They might look something like this:

div#layout {display: grid-layout;}
div.hgroup {display: grid-layout-group;}
div.cell {display: grid-layout-box;}

…for which we could simply substitute the table values mentioned earlier, and get the same result.  Why reinvent that particular wheel, especially when the new wheel would take even more years to be adopted?

There are only bigger problems lurking in related proposals.  A common request is a way to set the height of one element to equal another element.  Here’s the problem:

div#one {height: element(div[id="two"]);} /* totally bogus CSS-like example */
div#two {height: element(div[id="one"]);} /* DO NOT TRY THIS; IT WON'T WORK */

An infinite loop!  Yay!  Now what?  Furthermore, assuming you have a way to break the loop, which of the two elements in question will be the one that’s actually used to set the height for both?  There’s nothing in that set of rules that says that the taller of the two should win out, so you might end up with the two element set to the height of the shorter of the two.  What are the odds that’s what was desired?  (Non-zero, but pretty darned small.)  Then again, it might be the taller of the two.  Or maybe they’ll set to the average of the two elements’ content heights, so you get one too tall for its content and one that’s too short.

And this is a simple case, one that could probably be fairly easily resolved.  The complicated cases are where real trouble sets in, because you can get runaway situations where two (or three or more) elements keep triggering growth in each other, heading for infinity as fast as your rendering engine can calculate it.  If you allow value expressions—another common request—then it gets even worse.  For example:

div#one {height: element(div[id="two"]);}    /* see previous warning */
div#two {height: expression(element(div[id="one"])+25px);}

Ruh-roh, Raggy.

You might say, “Well, if any author is dumb enough to do that, then they get what they deserve.”  Only the author doesn’t get it, the reader does.  If you come across such a page, your (height-linking and expression capable) browser will freak out, maybe even crash.  Hopefully the developers made sure to add infinite-loop checks to prevent such nastiness, but are you sure they’ll manage to catch every possible case?  Without standing in the way of legitimate iterative processes?

And so we come back full circle to the present, where the only real choice for grid-dependent layouts are tables.  They should always be simple tables, employing a bare minimum of markup and styling the cell contents with CSS.  You can do that easily enough by ID’ing the cells, and writing your CSS accordingly.

And remember: this is only necessary for grid-dependent layouts.  Most layouts don’t fit that description, as I said in the previous post.  The only one that comes to mind at this moment is CNN.com, which has all those various boxes that need to line up just so (in the current design, anyway) even though there’s no guarantee of how tall or short they’ll be from one hour to the next.  They use tables to get those boxes to line up, as well they should—really, as well they have to, because there’s nothing else they could do outside of creating an all-Flash site.  But for the vast majority of sites, as Doug said, there’s no reason to use tables for layout.

Seven Responses

    • #1
    • Pingback
    • Sun 5 Sep 2004
    • 2319
    Received from Randomize - In Search of Tableless HTML

    […] hen I do, it is because the cure is definitely worse than the problem.

    Update: a mostly concurring opinion by Eric Meyer (the same author of the original piece). […]

    • #2
    • Pingback
    • Sun 5 Sep 2004
    • 2319
    Received from Randomize - In Search of Tableless HTML

    […] hen I do, it is because the cure is definitely worse than the problem.

    Update: a mostly concurring opinion by Eric Meyer (the same author of the original piece). […]

    • #3
    • Pingback
    • Mon 6 Sep 2004
    • 0907
    Received from Weblog de logicanova.com

    […] as para discapacitados… entre otras cualidades. En la bitácora de Eric Meyer hay un artículo sobre el diseño de una tabla 3×3 sin usar tablas de una manera rea […]

    • #4
    • Pingback
    • Fri 23 Dec 2005
    • 1036
    Received from Jill and Yuval’s musings » Blog Archive » CSS positioning does not negate using tables

    […] ust to display data in tabular format. No one will die, I will not tell and definitely the CSS god allows that. Tables are for tables. Posted in General | By y […]

    • #5
    • Pingback
    • Wed 11 Apr 2007
    • 2010
    Received from Triple Jeah Electronic Media Services LLC

    […] tables. And hell, there may be a few times when a table layout is required. Way back in 2004, Eric states that a table would be more ideal because it offers cleaner markup. With the example he […]

    • #6
    • Pingback
    • Wed 21 May 2008
    • 0748
    Received from NETTUTS - Web development tutorials and links - Which CSS Grid Framework Should You Use for Web Design?

    […] Not all designers support the use of using grid frameworks over tables, or even at all. But let’s face it; there are layouts you simply can’t do with just HTML tables without a great deal of painful effort – and lots of nesting that’s hard to decipher, should ever have to make changes. […]

    • #7
    • Pingback
    • Sat 5 Jul 2008
    • 0737
    Received from Ethos Blog » Blog Archive » Which CSS Grid Framework

    […] Not all designers support the use of using grid frameworks over tables, or even at all. But let’s face it; there are layouts you simply can’t do with just HTML tables without a great deal of painful effort – and lots of nesting that’s hard to decipher, should ever have to make changes. […]


September 2004
SMTWTFS
August October
 1234
567891011
12131415161718
19202122232425
2627282930  

Sidestep

Feeds

Extras