Like many developers who had seen the work-in-progress CSS3 Layout specification I was immediately horrified. As one commenter on Reddit said: “Argh. ASCII-art drawing for columns?” which summarizes my initial feeling pretty well.
Now I felt that way until seeing this example from the CSS3 Layout spec document:
"a . b . c" /2em ". . . . ." /1em "d . e . f" ". . . . ." /1em "g . h . i" /2em 5em 1em * 1em 10em
I could immediately determine what the template was trying to do and how the document was going to look. Even if it is kind of crazy at first glance I’m dying for something like this to be implemented. To create an equivalent document using the CSS that we have now – or even Tables – would absolutely futile.
Even the syntax isn’t that bad when you look at it. When examining the example I can see that there are three significant rows of content (two of which are 2em high and one of which will expand to fill the full height) and two spacer rows (each are 1em high). Thinking about how to implement something like this using normal CSS now makes my mind explode in frustration – especially in cross-browser manner.
So while this templating layout is still, very much, in the pipe dream category (no one will even touch it until IE implements it) I think it has a lot of merit and should be strongly examined – especially beyond the initial shock of the new syntax.
Honestly, this is just a goldmine waiting for some enterprising developer to come along and use the syntax to build a solution that’ll work in all current browsers (maybe a server-side, or JavaScript, tool that’ll process the template and inject the right style rules using a grid CSS framework).
Adam Vandenberg (November 10, 2008 at 12:10 pm)
Usefulness aside, I’m horrified at the thought of a CSS spec that demands I code in a fixed-width font. So I would say that while the concept is neat, the syntax is, in fact, horrible.
Mark Hutton (November 10, 2008 at 12:54 pm)
After reading your post I remembered recently seeing a script which did some css3 layout emulation, it’s available here: http://www.cesaracebal.com/research/thesis/almcss/
Eduardo (November 10, 2008 at 12:58 pm)
“Usefulness aside, I’m horrified at the thought of a CSS spec that demands I code in a fixed-width font. So I would say that while the concept is neat, the syntax is, in fact, horrible.”
You are the first person I hear that aren’t using a fixed-width font for coding already.
James (November 10, 2008 at 1:09 pm)
@Eduardo, I use Monotype Corsiva for coding. ;)
Seb Duggan (November 10, 2008 at 1:11 pm)
Of course, even when it is implemented by the browsers, at least one of them is bound to mess it up so it’s unusable…
Colin Ramsay (November 10, 2008 at 1:30 pm)
@Adam V: Surely this doesn’t need a fixed-width font? It would help to use one, for readability, but you could tab it out to get the same effect.
damian (November 10, 2008 at 1:51 pm)
@adam do you code in comic sans?
John Campbell (November 10, 2008 at 3:06 pm)
This is trivial to achieve with cross browser CSS today. Float a & c and apply left and right margin to b, and “clear fix” the row. Of course this forces you to put a&c before b, but it is not like this layout is really difficult to achieve.
That being said, I am all for this. We get all the power of tables without markup in the html. The only drawback I see is that it makes progressive rendering impossible.
Rob (November 10, 2008 at 3:14 pm)
Re: “To create an equivalent document using the CSS that we have now – or even Tables – would absolutely futile.”
I took issue with that (or took the bait). Unless I misunderstand, it IS possible with tables, like so:
<table cellspacing="0" cellpadding="0" style="width:100%; height:100%;"><colgroup>
<col style="width:5em;" />
<col style="width:1em;" />
<col />
<col style="width:1em;" />
<col style="width:10em;" />
</colgroup>
<tr style="height:2em;">
<td>a</td>
<td></td>
<td>b</td>
<td></td>
<td>c</td>
</tr>
<tr style="height:1em;"></tr>
<tr>
<td>d</td>
<td></td>
<td>e</td>
<td></td>
<td>f</td>
</tr>
<tr style="height:1em;"></tr>
<tr style="height:2em;">
<td>g</td>
<td></td>
<td>h</td>
<td></td>
<td>i</td>
</tr>
</table>
It’s uglier than I hoped — I’d forgotten you can’t set individual cellspacing via “margin” (which would make sense), and have to do dummy cells and rows instead.
But it works NOW in IE, FF, Webkit, and Opera.
I’m not advocating tables for layout (lest I be lynched), just calling out their power to do some things CSS currently can’t.
Nosredna (November 10, 2008 at 3:32 pm)
I don’t know how we can be expected to maintain any kind of shock at the CSS3 Template Layout when we’re almost immediately confronted with the idea of someone coding in a proportional font.
My brain just hemorrhaged. There’s blood spurting out my left nostril.
It’s the most surprising thing I’ve heard anyone say since the dual-slit experiment was described to me.
Nosredna (November 10, 2008 at 3:50 pm)
I checked out Adam (of the proportional fonts). He’s actually created some pretty cool fonts…
http://adamv.com/fonts/
Do you have a newsletter, Adam? I’m up for shaking the cobwebs out of my head.
Ian Thomas (thelem) (November 10, 2008 at 4:26 pm)
What is it with the seemingly religion devotion to CSS-box-based layouts over table-based layouts that many people seem to hold. Sure, there were some horrible table-based layouts back in the day, but does that really mean we should abandon the idea completely?
Rob’s example above can be simplified further:
<table style="width:100%; height:100%; border-spacing: 1em;">
<colgroup>
<col style="width:5em;" />
<col />
<col style="width:10em;" />
</colgroup>
<tr style="height:2em;">
<td>a</td>
<td>b</td>
<td>c</td>
</tr>
<tr>
<td>d</td>
<td>e</td>
<td>f</td>
</tr>
<tr style="height:2em;">
<td>g</td>
<td>h</td>
<td>i</td>
</tr>
</table>
Admittedly this does leave a 1em border around the whole page, but that could be avoided with an extension to the border-spacing property. You also don’t have much chance to style the 1em spacers. This leads to dummy cells in Rob’s example, but it’s not unusual to nest DIVs to expand your styling options, which is the same thing really.
Boris (November 10, 2008 at 5:35 pm)
Rob, your example only works in quirks mode…
Sugendran (November 10, 2008 at 10:52 pm)
So… in terms of processing power required by the browser – how is this different from tables?
Eugene (November 10, 2008 at 11:51 pm)
I’d assume that it works similarly to tables, but layouts aren’t hindered by strange rendering of floats and borders and whatever.
Dmitrii 'Mamut' Dimandt (November 11, 2008 at 3:41 am)
See TerraInformatica’s HTMLayout, http://www.terrainformatica.com/htmlayout/main.whtm
It shows that you actually need only two additions to existing CSS to make it work beautifully with complex layouts:
%%units, http://www.terrainformatica.com/htmlayout/fspu.whtm
flow, http://www.terrainformatica.com/htmlayout/flow.whtm
that’s it! no ASCII art is required :)
Ufortunately, Andrei Fedonyuk is but one voice in the vast expanses of w3c’s mailing lists…
Now wait when this CSS3 loayou begins clashing with floats and relatively positioned elements…. Ugh…
Ralfe (November 11, 2008 at 4:12 am)
I can’t begin to imagine how Internet Explorer is going to mess this one up. Everyone, brace yourselves!
Nicholas Shanks (November 11, 2008 at 4:25 am)
The tables-for-layout mechanism is very powerful. Why not translate it more directly to CSS, without resorting to display:table-cell and stuff like that:
#container { display: grid; rows: 5; columns: 3; }
#container::cell(1,1) { colspan: 2; rowspan: 4; width: 66%; height: auto; content: url(#main); }
etc etc.
#main would just be a div inside #container. The CSS affects the layout, but the document can be ordered as the author likes.
Andrew Dupont (November 11, 2008 at 1:58 pm)
Two questions, both relating to the JavaScript style APIs.
First: Take any of the more complex examples in the spec. How will it look when one does something like
$('#container').css("display")? Will all browsers normalize the string the same way? I hope so.Second:
$('#container').hide()will change the element’sdisplaytonone. What happens when it’s shown again? Now libraries will have to store the originaldisplayvalue in an expando, I suppose.But doesn’t this illustrate why the CSS display property sucks? Valid values include
none,table-cell, and now"a . b . c" /2em ". . . . ." /1em "d . e . f" ". . . . ." /1em "g . h . i" /2em 5em 1em * 1em 10em? This is like Dwight’s bed-and-breakfast, where each room has a theme: America, Irrigation, and Nighttime.Edwin Martin (November 11, 2008 at 4:21 pm)
After seeing the example I’m still with the Reddit user.
The simplicity of the CSS-syntax is pretty much killed here.
If we agree using tables for layout is bad, then using a solution that is worse should be out of the question.
Jos Hirth (November 11, 2008 at 6:15 pm)
>If we agree using tables for layout is bad, then using a solution that
>is worse should be out of the question.
It’s pretty simple actually. The big idea is that you don’t need a matching structure anymore. As long as there are some ids or classes attached (as long as it’s selectable) you can rearrange it like you want.
You can for example put the actual content of the site at the very beginning and you also don’t need to worry about the markup created by random controls/components/modules of your CMS.
You can place them wherever you want without having to modify the underlying logic (which usually isn’t desirable if you intend to reuse existing components).
naught101 (November 27, 2008 at 3:02 am)
@IanWhat is it with the seemingly religion devotion to CSS-box-based layouts over table-based layouts that many people seem to hold. Sure, there were some horrible table-based layouts back in the day, but does that really mean we should abandon the idea completely?
Well said. The ridiculousness of the CSS grid spec is testament to that: exactly the same problem as tables layout, but with a different name.
@JosThe big idea is that you don’t need a matching structure anymore
Exactly! Now we can have a useful, intelligent XML structure that can be exactly the same across thousands of different sites, regardless of where the navigation bar is, or if the sidebar is left or right. Brilliant!
Edwin: if you think this solution is worse, you don’t understand the problem.
Nicholas: That is a brilliant proposal – I was thinking of something along the same lines yesterday, although I hadn’t fleshed it out the way you have.
naught101 (November 27, 2008 at 4:50 am)
The only serious problem I see for this system is graceful decay. What will a page defined thus look like? Basically just like straight HTML, with no layout (in other words, navigation down the bottom, instead of visually being at the top, etc.). It wouldn’t be unusable, but it sure wouldn’t be pretty.
Then, of course, you have the chicken and the egg problem: if browsers don’t take it up, designers won’t, if designers don’t take it up, browsers won’t.
About the only way out of that bind is to have an industry-wide (most large players) agreement to implement this by a certain date. That means Microsoft, Mozilla, Apple, Opera, and Google, all having it implemented within a version of each other. I wonder if that’s possible? The largest problem there would be difficulty in getting IE users to update (~20-25% of the world still uses ie6!@#$).
naught101 (November 28, 2008 at 7:11 am)
Some of my criticisms, and an extension on Nicholas’ proposal: CSS3 advanced layout module: templates. Discussion and proposal.
Matt Wilcox (December 10, 2008 at 8:44 am)
I’m still convinced that the Advanced Layout module is entirely the wrong approach to our layout issues.
What it provides is a template system for a table-esque layout. Not good enough! Not flexible enough, not what is required by designers.
Why are we STILL thinking of web design in terms of table-esque layout? Why is CSS STILL providing nothing but options to shoe-horn content into pre-defined boxes? NOT good enough!
What CSS needs to enable flexible layout is jQuery-like DOM inspection and manipulation. It needs math. CSS does NOT need yet more inappropriate Modules that solve only very specific issues. CSS needs to provide tools with which designers can create their own solutions.
I wrote a post about the fundamental problems with CSS and the steps required to fix it here, for anyone interested: http://mattwilcox.net/archive/entry/id/1031/
Mr. CSS (December 10, 2008 at 5:16 pm)
When I think of grid syntax for CSS, I think of something like that:
#my_grid {
display: grid;
}
#grid_row1 {
display: grid-row; parent-grid: #my_grid;
height: 1em;
}
#grid_row2 {
display: grid-row;
parent-grid: #my_grid;
height: 2em;
}
#grid_col1 {
display: grid-col; parent-grid: #my_grid;
width: 33%;
}
#grid_col2 {
display: grid-col; parent-grid: #my_grid;
width: auto; margin: 1em;
}
#grid_col3 {
display: grid-col; parent-grid: #my_grid;
width: 20%;
}
#cell_11 {
display: grid-cell; parent-grid: #my_grid; grid-position: 1, 1;
grid-cell-rowspan: 2; // takes 2 grid rows in column
}
#cell_21 {
display: grid-cell; parent-grid: #my_grid; grid-position: 2, 1;
grid-cell-colspan: 3; // takes 3 grid columns in row
}
/* ... and so on... */
It’s not very simple, but very flexible – let’s you do everything with grids. In html code, elements don’t have to appear in any special order. They are put into grid by ‘grid-position’ rules.
grid-row’s and grid-column’s don’t have to (even shuldn’t) exist in html code. They are just put in css as “virtual” ids to allow referencing them in other rules.
John A. Bilicki III (December 17, 2008 at 5:06 am)
My entire website is viewable (albeit not entirely) in IE4 and Opera 4 (albeit with secondary CSS for fixes though CSS2 related). My site has a fluid/tableless layout and is served by default as application/xhtml+xml and *still* works in older browsers reasonably well. Frankly all it takes is an afternoon of building a fluid layout that validates as only CSS1 and this becomes nonsense. Besides CSS3 is bringing us box-sizing any way (with support in IE8) so I don’t see how this is anything except a redundant attempt at people’s inability to understand the *first* version of CSS except…
…there is the challenge of optimizing what content is placed at which parts of the page. Still I prefer Yahoo’s
implementation. If all the search engines adapted this then instead of going to the extent I’m seeing in just a short glimpse on the linked W3C page we could stick to the basics…those of us are actually actively practicing it at least.