(last edited on February 6, 2019 at 12:30 pm)
I’ve been taking a break from coding the webapp framework to do some thinking about design. Specifically: typography.
I’m pretty fussy about the way a page is organized when I’m writing documentation, and this carries over to the way that I design screens. To me, a beautiful screen design has a rhythm to it. And when designing information-heavy pages, I’m thinking about how to do that mostly with words and graphic treatments that show the relationship between them. Secondly, as a documentation writer, I like clean typography with headers, tables, and lists that are harmoniously spaced and weighted.
I’ve decided to start the design with the words in mind, which suggests the use of a baseline grid. A baseline is the imaginary line on which all the letters sit:
A nice thing about baseline grids is that the repeating rhythm is very pleasing to the eye because it is calming. A competently-designed multi-column print piece has the baselines of text aligned, which creates a powerful sense of unity across the page. Secondly, when you have seas of calm typography, that gives you something to break out of to attract attention.
To implement a baseline grid in HTML/CSS, you have to use the
line-height tags judiciously, as well as ensuring that all the block elements you use are some multiple of the line-height. For my first grid, I decided to use a multiple of 72 pixels, which is sort of a traditional number in the world of printing. An 18 pixel-high line with a 12-pixel font-size gives me a linespacing of one-and-a-half (1.5) lines. So, my basic building block is an 18-pixel square. Here’s what I ended up with:
There are 36 pixels boundaries on the left and right, and a 36-pixel gutter running between the columns. The left column is 288 pixels wide, and the right is 522 pixels wide. These looked the most pleasing to me, given the line spacing and font size. I also applied full justification (
text-align: justify) to the right-side column just to see what it would look like. Usually, full justification looks awful on a web browser, and it’s borderline unacceptable here; the test is to compare the spaces between the words with the spacing between the lines. When the word spacing is not half the linespacing, it creates “rivers” of space running down the page…bigger gaps between words than the lines makes the text group vertically, not horizontally. Since we want peoples eyes to read horizontally, these rivers create problems as they tend to attract our eye downward. This can be adjusted by using MORE line spacing, but it makes the page a little different looking.
Incidentally, there is a well-known baseline grid designer framework from Stéphane Curzi, but rather than use it I wanted to build one from scratch so I would be more familiar with the typographic controls in CSS. I also have a different preference for my header spacing and weighting. I adjust them to be slightly off the baseline grid so the spaces between the header baseline and the content that comes before and afterwards is also pleasing, roughly on thirds to enforce gestalt (grouping of the header) and provide some counterpoint in spacing. I think it looks nice. Otherwise, my grid is very similar to Curzi’s, though his CSS is far more comprehensive. The reading on his website site is also very educational if you want to know more about the history of baseline grids. Check it out!
Thoughts on 18-pixel Blocks
There is no reason why 18 pixels is the unit size. It’s actually probably a little too small for universal reading, but it’s a very traditional unit to start with because 72 points per inch is so ingrained in printing and typography. 72 is also a number that has a large number of divisors; it can be divided by 2, 3, 4, 6, 8, 9, 12, 18, 24, 36 evenly, which adds some flexibility in making equal divisions in your grid. Just as flexible is the use of 60 as a base. Let’s compare:
Divisors of 72: 2, 3, 4, 6, 8, 9, 12, 18, 24, 36 Divisors of 60: 2, 3, 4, 5, 6, 10, 12, 15, 20, 30
If I wanted to increase the font-size slightly and maintain the line-height ratio of 1.5, then I’m looking at the following choices:
12px / 18px - approximate to 9pt 13px / 20px - approximate to 10pt 14px / 21px 15px / 23px - approximate to 11pt 16px / 24px - approximate to 12pt
I played around experimentally to see how Chrome rendered “pixels versus points” by changing the
font-size property. In general, 9pt is considered small type, and 12pt is an acceptable minimum size for older readers. In the future, I would choose a grid based on the audience and ambiance of the page, and then find a multiple that works with the grid I want to use. I also have to maintain integer ratios between the
line-height properties for all the calculations to work correctly in creating a baseline grid. The beauty of 12/18 is that the line-spacing property can be exactly 1.5 (it’s a multiple of the font-size). Compare this to 13/20: the ratio is 1.53846… this is a problem because when the browser calculates the line-heights to draw the screen, small numerical inaccuracies build up as you go down the page, which breaks the baseline grid alignment between columns. You can work around this by specifying pixel-based line-heights (e.g.
font-size:12px;line-height:18px; as opposed to
font-size:12px;line-height:1.5; as I do.
While the baseline grid is theoretically beautiful and ordered, I personally find it a little bland. I’m not sure why that is; perhaps it has to do with the squareness and predictability of it. It’s possible to build grids out of different ratios, of course, and it’s also perfectly OK to place an element off-grid. This can be very interesting, because this breaks the expectation and stands out. Consider the following pattern examples:
1 | | | | | | | | | | | | | | | | | | | | | |
The very first line is a regular pattern. It’s precise, but kind of boring. That’s because our visual system actually is very good at perceiving patterns and then tuning them out; knowing this is the basis for knowing how to control visual hierarchy on the page.
2 | | | | | | ||||||| | | | | | | | | | | | | |
The second line shows an increase in one section without disrupting the pattern in which it lives. This creates a point of mystery. However, this could be de-emphasized if it was placed in such a way that it neatly divides the line into two halves:
3 | | | | | | | | | ||||||| | | | | | | | | | |
Now the pattern has become a point of central interest, but it’s a little less dynamic. It turns into a subpattern if we do this:
4 | | | | | | |||| | | | | | | |||| | | | | | |
Now there are two patterns interwoven. It’s a little more interesting than the first pattern, but it is also resolved and therefore easy to stop looking at, once it is understood. Finally, consider the following pattern.
5 | | | | | | | | | | | | | | | | | | | | | |
On first glance, this looks like the same pattern as 1, except there are two misplaced lines. It’s just slightly askew; some people are quite sensitive to this and will notice it right away. The problem with this is that is looks sloppy and it’s hard to tell the intent of the person who drew it: is it supposed to be a regular pattern? That creates ambiguity in the meaning. If it’s supposed to be sloppy, it should be more obviously sloppy. If it’s supposed to be regular, then make it perfectly regular.
This is the basic understanding that guides my application of a baseline grid. Ideally, it creates solid grid so we can selectively place points of interest and maintain overall unity on the page. We can break out of the grid pattern to jump out, for items that we perhaps need the reader to see first before reading subsequent text; the most contrasting element tends to stand out first. We can also place content (images, for example, or headers) in places where they stand out to signal a change, encountered in the linear progression of our eyes through the ordered content.
Speaking of headers, mine use asymmetrical spacing. There’s more space before the header than after, since I want the header to be grouped visually with its following content. The exception to this rule is for the H3; the space is even, and similar in size to the H1 and H2 “after space” between header and following text. Since I usually use H3s for chaining sequential sections together, this helps maintain the visual flow of the entire document because the negative spaces create a linking pattern. This is a convention that I use, however, in my writing. Other people probably would prefer to have a regular asymmetrical H3 spacing to be consistent (I might add one). If I don’t need an H3, I skip it and use an H4 for subcontent headings, or I just use H2s. I’m still actually on the fence about the H2 spacing.
The grid is so boring because there are no larger blocks of content; this is pretty much a straight chunk of text. There is also very little scale variation, other than in the headers, and no balancing use of image. This would get much more interesting making sure that there’s plenty of whitespace, with page-sized graphic elements to balance things out. A sub-grid can be applied, like the compositional rule of thirds or constructing a grid based on what’s in the image. There’s a pretty nice grid review on the marvelous Thinking with Type book site, demonstrating how asymmetrical spaces can liven up a layout.
Other Implementation Notes
As far as code goes, this is a decent starting point, but for greater flexibility I want to rewrite the CSS to use calculated values. That means converting the CSS file to PHP so I can change the key variables of
line-spacing and then properly calculate the margins and padding for all other elements to stay on the baseline. Since there is no way of specifying margin and padding in terms of font size in CSS, PHP will have to be my stand-in.
The most recent version of this file will be at http://davidseah.net/baseline-css.