CSS Gridlock
Published 20 years, 2 months past
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.