Thursday, 10th August 2017

Grids from print to web: an experiment

So now grids are here in CSS, and we finally have ways of laying out web pages that don’t rely on abusing things like floats that were never really meant to describe the layout of an entire page (if that metaphor still works).

I’ve been working on the web for a long time - the first job I had as a full time web designer also had an element of print design. Sometimes I’d be working on websites, sometimes on museum catalogues.

For my print work, back in the early 00s, I started to see that grids were a really useful thing for print designers and started to get very interested in how they worked. Luckily I worked for a university and was able to rifle through their massive selection of design books, including several shelf metres of grid design books.

What I slowly realised was two things:

A test for myself

So what I thought I would do would be to take a print layout and try recreating it in CSS grid. There are parts of my brain that know this is slightly pointless but I think it’s useful for me to see where there might be either gaps in my knowledge of the spec, or a way of being able to identify where my print processes are no longer helpful - or even worse, holding back - the way I should think about web layouts.

So I chose a book called How to be a graphic designer without losing your soul which was designed by Bibliotheque. If you go and have a look at the layouts you can see that there is a definite grid but it’s complex - the text block is modulated, bits chopped out of it, tension applied. It’s not just content poured into a box.

The old process

So the first thing I would have normally done when working on a new book would be to choose a typeface. For me it’s the way in - knowing about the history and origins of different typefaces helps me choose, even if no-one else makes the connection. So if it’s a poster about 1930s furniture: Gill Sans, obviously (probably too obviously - maybe Futura or Kabel next time).

Once I’ve chosen a typeface or two, then I would ‘audition’ it. I’d set it in a few different sizes and line heights, keeping the line length around 65 characters, and print out all these experiments on paper. Like ‘deciding in the browser’ I think it’s a pretty good rule that the way the visitor will experience it is the way that you need to decide if it works or not.

The reason why I did all this is to get to the line-height - the line-height is the starting point for the grid for me. So once I had a font-size I was happy with, I’d try different variations of line-height, tuning it to get the balance of white space and dark letters. The line-height would then become the basis for the grid’s height (as a multiple of the line-height) and the gutters between the grid cells. It also tended to serve as the indent for the paragraphs in the text block.

The vertical grid modules would usually be an odd number based on intuition of the content of the book. I would usually have images to incorporate into the grid, or if there was text I would look at having say three columns of content on a 7 column grid - each column spanning two grid modules each with a spare column to create some white space, or give me somewhere to add a pull quote - anything to reduce the monotony of identical columns of text.

So a grid for print design is caught up in a lot of other design decisions - there’s a mesh of typography, line-height and the size of the printed canvas, as the grid would sit within the margins of the page.

Most importantly, during the actual creation of the book, the grid could change if one of those variables changed. Pages could be ‘off the grid’, or ignore the grid, or be on the grid but rethought, shifted and adjusted to different points on the grid later. Grids were a space to play and the rules could change before the game was over.

Reproducing the process with CSS

So how close can we get to expressing these sorts of print layouts in code? (spoiler: here’s the codepen of the finished thing.) From looking at the layouts of How to be… I think they’ve used a nine column grid - usually there are more columns that you see in the finished layout to give you more options.

So I would set that up like this:

display: grid;
grid-template-columns: 1fr 1fr 1fr 1fr 1fr 1fr 1fr 1fr 1fr;

That will give me a nine column grid - and by using fr it will also mean that the browser will get the exciting job of working out what the widths will be (it used to take ages).

Line-heights

Now we run up against the first problem. line-height is unitless in CSS - it’s a multiple of the font-size, so you’d normally do something like:

font-size: 1.3rem;
line-height: 1.4;

and the browser will work it out. Which makes perfect sense - it keeps everything relative. So is there a way of having a grid-gap that is somehow related to the line height? grid-gap can take a percentage or a length value. I settled on using calc to do the same calculation the browser does to create the line-height, so:

font-size: 1em;
line-height: 1.35;
grid-gap: calc(1em * 1.35);

So we’ve created a grid that, as before in print, relates the spacing between elements to the line-height.

Adding content

Now we need to add some content to our grid. I’ve looked at page 35 of the book, which is all text, and has five paragraphs, the first 2 from the 1st to 5th module of the grid, the next 2 from the 2nd to the 9th module of the grid, and the 5th paragraph back to the 1st to 5th module - similar to the layouts you can see on the designer’s website.

I initially just put some paragraphs inside main, expecting firefox to just make them 100% of the width of the page. When I looked at the output in the browser I realised that firefox seemed to be treating each paragraph as a separate grid element, as the paragraphs were direct children of main, and giving each paragraph one fraction to sit within.

One of the things that most worried me about recreating the print grid was the way that each paragraph wasn’t on the same left alignment. So looking at this unexpected (to me) behaviour now, I see I can treat each paragraph as a separate layout element and move them around within the grid:

main p:nth-child(1) {
    grid-column-start: 1;
    grid-column-end: 6;
}
main p:nth-child(2) {
    grid-column-start: 1;
    grid-column-end: 6;
}

I’ve still not got used to having to say grid-column-end:6 when I want the grid item to span five modules, and having to say grid-column-end:10 when there are only 9 modules is a little bit odd.

I was surprised how quickly I was able to reproduce the grid layout of one of the pages of the book using CSS grid. The only thing that I didn’t expect was that giving each paragraph a grid-column-start and grid-column-end would mean that each one would create a grid-row. I got around this by turning the grid-gap off for the horizontal elements - grid-gap can take two values:

grid-gap: 0 calc(1em * 1.35); /* rows then columns */

Grid rows and multiple grids?

The layout I’m trying to reconstruct doesn’t have much in the way of horizontal alignment across pages so I’ve not thought a lot about grid-row so far. But for most layouts the rows would be important.

So in a lot of cases I can see there needing to be two or more grid layouts in the CSS for a page - one controlling the complete page layout, the other controlling the layout of the main page content. This is a little counter to the way you’d work with grids in print, as normally you’d think of one grid controlling the entire layout, with everything on your design automatically related to it. In InDesign, for example, grid lines appear above everything on the page. I think this is where display:subgrid would be really useful. I’ve faked subgrids with SASS but it seems like a bit of a hack.

Adding the footnotes

An important part of this design is the footnotes in blue. It was pretty straightforward to figure out how to fit them into the grid that had been create, and using align-self: end; meant that I could align them to the bottom of the grid module rather than have them at the top of the paragraph they were visually connected to.

The finished layout…

The finished layout is on codepen.

Same or different?

I learned a lot trying to translate a print grid into a web format. Of course for small screen sizes there isn’t much layout you can add to the content, but at bigger sizes grid helps you create dynamic layouts which break out of the header, column of undifferentiated content, footer pattern.

I also found it really useful to try translating something from another medium into web. As I was working on this example I realised that there would be lots of problems if this content was added through a CMS: if someone came back and added an extra paragraph the layout would fall apart because of the nth-child declarations in the CSS. The layout is brittle, but if print designers can spend time looking at every single element of a story layout in a magazine, why can’t we do the same thing with the on-line version? Maybe our tools need to allow more description, more metadata, around our content.

For me I would love to be able to have a single grid for the entire page, and be able to use regions or another way of locating different content - even possibly within the same container - within the grid. Being able to say in CSS that ‘all the pullquotes within this div will start from the second grid column and all the paragraphs from the third’ would be really useful, or being able to tell the same content to flow from this grid area to that grid area if needed. Being able to run text around photographs and keep everything in the grid would be excellent, as would being able to set a single baseline grid and have line-heights for different font-sizes relate to that automatically. I’m sure a lot of these things are there - it’ll just take time to translate knowledge from one process to another.

But the tools we have now are way beyond what we’ve had in the past, and I’m excited to work with these new tools and stretch my ideas of what web layouts can be.