I recently wrote a feature for .net Magazine, The Future of CSS Layouts, which took a look at several proposed CSS modules intended to provide more flexibility for laying out websites. One of those modules, Grid Layout, has been experimentally implemented in IE10 Platform Preview, and it prompted Mark Boulton to propose an alternative approach in his article Rethinking CSS Grids.
While I think the alternative syntax is pretty robust, I did detect a couple of flaws in it which I promised Mark I would write about, and that’s what I’ll do in this article. Before I get to that, I just want to quickly address one of the key points from his proposal.
Defining a Grid
grids have been around for quite a while and there is established words for things like Columns, Fields, Modules and Gutters. It’s my feeling that the CSS grid module should speak the same language as designers, not that of developers.
I’m not certain that I wholeheartedly agree with this; not that the Grid Layout syntax uses terms that are more familiar from tables or spreadsheets rather than typographic grids, as this is certainly true; but the contention in the second sentence, that the Grid module should be aimed at designers rather than developers.
The language of grids may be obvious to those that are trained in using them, but I wonder just how many people that includes. For the non-typographically savvy I think it’s not as literal; speaking for myself I find Rows and Cells more logical than Fields and Modules.
And while Mark’s proposed syntax works well for typographic grids, it does mean that making an irregular grid becomes extremely hard. Using the Grid Layout syntax you can make regular and irregular grids very easily, whereas this new proposal is really intended only to make one very strict type of grid.
Anyway, that’s kind of besides the point; I’m not strongly convinced of my own argument, just thought it was worth raising. But I’ll take Mark’s premise at face value and go along with the syntax that he proposes. If that’s a more logical way to think about grids, then the syntax seems pretty solid. There are, however, a few potential problems I can see with it.
Fractions
The first problem is that basing the grid on modules eliminates the effectiveness of the fr (fraction) unit. In the example in section 4 of the article a three column grid is created using this code (NB: I’ve changed some of the values a little to bring them into line with existing properties):
div {
grid-columns: 3md 1fr 2md;
grid-x-count: 10;
}
As this is on a grid made of 10 horizontal modules, the central column is five modules wide. But what if we used four columns, with two fraction units?
div { grid-columns: 3md 1fr 1fr 2md; }
That would make the second and third columns 2.5 modules wide. I’m presuming that we can’t have fractions of modules, so if the fraction unit can’t be used to create fractions then it becomes useless (or, at least, very hard to work with). In this case we should just go back to using the md unit for everything:
div { grid-columns: 3md 5md 2md; }
And if we’re doing it this way, then we don’t need the proposed grid-x-count property any more; that count can be obtained by the sum of the md units in grid-columns. This brings it a little closer to the existing Grid Layout syntax.
Breaking the Grid
The second problem is that the grid is now very hard to break out of. What if, after we’ve laid out our grid, we wanted to put an item that broke into the gutters:
How do I position that? Unlike in the Grid Layout syntax, gutters aren’t available as slots to position elements in. I could use relative positioning to move it into the gutter, but how do I also expand the element so that it’s larger than the modules it covers? Maybe with padding:
div {
left: -21px;
padding: 21px;
position: relative;
top: -21px;
}
But if, in this box model, padding is added to make the element bigger, then how would I put put internal padding on an element which I didn’t want to get bigger? A possible alternative solution to this would be to add a new property, something like:
grid-gutter-span: all;
This could also have the keywords top, right, bottom, left, or none, to provide flexibility to the elements that are placed in the grid.
Conclusion
For defining a typographic grid I think this syntax is pretty well thought out, certainly for a first draft, and the problems I’ve pointed out here are not insurmountable, but just require some more consideration. I hope that the feedback I’ve given is constructive — well, most of all I hope that I’ve understood the proposed syntax correctly and not made any stupid mistakes! If you’ve anything you’d like to add, feel free to leave a comment.
I may be misunderstanding the terminology, but is a ‘typographic grid’ the same sort of thing as what’s being specced in the CSS Line Grid module?
Rob
@Rob: That seems to describe a baseline grid, for providing vertical rhythm. Interesting find, thanks.
Thanks for the thoughtful response, Peter.
I’ll try to address some of your questions:
It’s a terminology thing. I’d rather that Rows and Cells are reserved exclusively to Data tables. Once we start to blur those lines again (and undo the good work the Web Standards movement did), we get onto dodgy ground.
That’s a fair point. Maybe I should clarify that, of course, the terminology needs to make sense to everyone, but as this is a *layout* module, there is terminology that has been used for decades to describe these things. Why reinvent the wheel?
Irregular (or Asymmetric, as they’re called) grids use two or more module sizes. I think this would be possible by combining declared module sizes with x-counts and positions. I don’t think it would be difficult.
Maybe something like:
div {
display: grid;
grid-module-1: 50px 30px, x-count=3;
grid-module-2: 80px 30px, x-count=2;
grid-module-3: 50px 30px, x-count=3;
}
I disagree (as I said above). Declaring different module sizes is how you create asymmetric grids. This proposal also allows you to create modular grids (as seen in my example), and columnar grids. And baseline grids. The other type of grid that will be tricky are Axial grids (which pivot around a point in space).
Great idea. You may well indeed to hang elements into the gutter. However, sometimes that ‘hang’ is not the width of the gutter, but a portion of it (for certain glyphs, keylines, tinted boxes etc). So, we’d need to be able to declare a measurement of the hang.