A. M. Douglas

Future CSS grids

By now, if you're a frequent web trawler like me, you'll have come across articles discussing the new CSS Grid spec. The Grid is touted as a harbinger of an end to markup-dependent grid systems, like those offered by Bootstrap, Foundation, PureCSS, BassCSS, Bourbon Neat and so on. After reading this article by the spec's lead developer and advocate, Rachel Andrew, I see that the future is much brighter thanks to display: grid.

Initial Scepticism

Yes, I was very, very sceptical of the Grid spec, partially because of its exceptionally low level of support in even the latest browsers. I use Chrome 49 on my recreational computer and even then I can only see CSS Grid properties at work because one of the command line flags I run just happened to include Grid draft spec support.

Obviously the level of support will improve with time, but it's a powerful disincentive to actually giving the spec the time of day—I only gave flexbox a chance when support reached around 80%-85%, and it's not something I use in production. For clients, I'm all about float and display: inline-block.

Another reason for my scepticism was that the syntax looked, frankly, like more work and hassle for similar results.

What about Flexbox for layout?

Some people looking at the Grid spec might question the use of it with respect to the fairly well-supported flexbox option.

I recently developed a grid framework based on display: flex, and while it was relatively straightforward undertaking, and while it was a valuable exercise, I still couldn't help but find the end result a ugly. I couldn't help but find the possibilities of Flexbox being a little limited in some ways and a little overcomplicated in others.

Sure, the end result is a bit more versatile than traditional solutions, and Flexbox layouts are easily manipulated by switching between different flex-directions and align-items/align-self properties, but ultimately the basic form of the flexbox grid is equivalent to the same kind of grid achievable with display: inline-block—it's just a little bit easier to guarantee that the grid will look correct.

Of course, this comes at the cost of native browser support for some legacy clients, and that's actually not something that should be scoffed at. When you're actually working with businesses and service providers, your client is only the beginning of the story. You have to consider the end-user, and the end-user is not going to be running WebKit nightlies, Firefox Nightly edition or Chrome Canary.

Obviously everybody knows this, but the option to use the latest platform features is still here: you just need to conditionally load a bunch of polyfills—but I hate doing that.

display: grid

Originally, from a cursory glance of one or two examples, I saw nothing of value in CSS grids at all. The code appeared to be messy, less maintainable than present solutions.

I saw this CSS:

.wrapper {
  display: grid;
  grid-template-columns: 100px 10px 100px 10px 100px;
  grid-template-rows: auto 10px auto;
  background-color: #fff;
  color: #444
.box {
  background-color: #444;
  color: #fff;
  border-radius: 5px;
  padding: 20px;
  font-size: 150%
.a {
  grid-column: 1 / 4;
  grid-row: 1 / 2
.b {
  grid-column: 5 / 6;
  grid-row: 1 / 4
.c {
  grid-column: 1 / 2;
  grid-row: 3 / 4
.d {
  grid-column: 3 / 4;
  grid-row: 3 / 4

I may be subjective, you may even claim that I have bad taste, but nothing about this exemplary Grid CSS made me hungry for the spec. The warning lights began to flash immediately when I noticed that behaviour for each cell in the grid appeared to be defined precisely.

Now, if you're one of these developers who just feeds a bunch of crap CSS into a preprocessor and goes to lunch after delivering bloated, poorly understood code, maybe there's some build/task runner script that will automate this process, but I prefer to work with plain CSS and to establish high-level behaviours which cascade down, rather than micromanage every element in my web page.

So I ignored the Grid spec. I kept using traditional grid system patterns and eventually dabbled with Flexbox. That is, until today, when I had a read of the aforementioned article by Rachel Andrew.

There, I saw code like this:

.wrapper {
  grid-template-columns:repeat(12, 12fr);

That's a 12 column grid in 5 lines of CSS. Each of those columns will be sized exactly, and you can add gutters in a similarly precise way.

5 lines per media query (instead of redefining a .col-[x]-[y] for every breakpoint).

What's more, for those times where you need bigger grid cells and yet still need a general grid cell size/structure (think: featured products, product categories by popularity, etc.) you can define a particular grid cell size and the grid will essentially take care of the bin-packing for you, thanks to this beauty:


The Grid spec is going to revolutionise responsive web design. It's going to be trivial to establish mobile layouts and HTML will never have been so lean.


My advice to web developers approaching Flexbox is this: wait for the Grid to land in popular browsers. Stick to display: inline-block or float for grids. I know it's horrible, but it's the best thing you can do for your users at the moment.

If you must upgrade, don't require Flexbox. Offer it as a progressive enhancement; but know this: you really can't offer significant advantages with it. There's nothing that Flexbox can do that cannot be done with position: absolute, float or display: inline-block.

Flexbox makes some of these tasks simpler, and it may allow you to tidy your markup a bit, but its nothing compared to what the Grid spec will offer when it lands.

Be patient. Refine your tried-and-tested, robust (if old-fashioned) code. If it isn't broken, don't fix it. Spend some time using other browsers as your daily driver. It's insufficient to just check every now and again. You need to be aware of the little nuances, like trying to center Flexbox elements with margin:0 auto in Safari. Protip: it works in Chrome, Firefox, IE11... and not in Safari.

Labels: ,


Post a Comment