On Web Typography

Perhaps the highest compliment I can pay Jason Santa Maria is that his book On Web Typography is changing my handwriting.

Every morning I read, pray, and journal for a few minutes—and I recently noticed that I’ve been tweaking my script. I’ve adjusted my margins, fiddled with the space between lines, and tweaked the size of my letters. I’ve tested different pens with varying stroke widths.1 It’s as if reading the book opened up a subchannel in my brain where I examine the form of my handwritten words in the light of ideas pulled from Jason’s book.

To say that I eagerly anticipated this book would be an understatement—as far back as early 2013, I had it as a bullet point in my Wish List note in nvALT. I had to wait a bit longer than expected, but it proved to be very well worth the extra time. I’ve read the book about three times: first on my phone, then the paperback, and now I’m revisiting it on my Kindle.2 Compare that to my copy of Bringhurst’s Elements of Typographic Style, which I have yet to finish despite many attempts.

I’m no stranger to typography, but it still often feels like a second language to me. As a developer I have a pretty good grasp of the technical aspects of CSS and its properties with respect to setting type, but I’ve always lacked a method for the step that comes before that: choosing and pairing type. I’ve relied on intuition and gut feeling, going with what looked right. That’s a process that can sometimes produce good results, but mostly I just end up burning up time. What I like about the book is that it welcomes people like me into the fold, peeling back how Jason approaches type. His “type for a moment, type to live with” distinction is so simple, but it clarified something I’ve struggled with for years.

There’s an easygoing generosity to the book, and as I re-read it I’m struck with how little Jason holds back: it’s like being invited to hover over his shoulder as he explains how he goes about his work. That’s no small thing, and it’s difficult to pull off in a way that feels authoritative, natural, and humble.3 There is nothing I find more inspiring than talented people simply opening a door into the things that they love. You feel that joy in this book, and it’s infectious.

I still find choosing and pairing type challenging, but at least Jason has answered the basic question—What am I hoping to communicate?—and explained his approach to evaluating and selecting type. The properties of type aren’t treated in abstract, but are approached in the context of the typeface’s potential purpose. For me this helped transform typography from an arcane pursuit into something more approachable, now marked with handy guide posts to anchor my own explorations.

Above all, Jason reminded me that typography is there to serve a purpose. Writing about type to live with, he says:

You want that clear goblet. Help people forget that they’re staring at a screen and instead immerse them in the words and the story you’re telling. The type you use should be smooth, removing as much friction as possible between the reader and the text.

In a way that passage sums up this book for me: it lessened the friction introduced by technical components like x-heights and stroke contrast, and situated those components in a story about type. I can’t help but hope for a follow-up volume.


  1. Uniball Signo DX (.38) vs Pilot Hi-Tec C (.3), lately. 
  2. Ironically, that experience underscores how terribly the Kindle executes basic typography. 
  3. I should pause here and thank editor Tina Lee for this. 

Progressively Enhancing Progressive Enhancement

Last Friday I made a joke on Twitter about progressively enhancing the progressive enhancement on a site—turtles all the way down, ha ha. But in some ways I was being quite serious. One of the beautiful things about working on the web is that a site is never truly done, sometimes for worse but usually for the better. You can keep improving things iteratively, smoothing over the rough edges that may have existed at launch.

The Essay and Voices in Time articles on Lapham’s Quarterly feature random artwork and quotes (random in a sense that they’re only tangentially related to the article). Every issue has an associated pool of artwork and quotes, and each time we load an article we dip into that pool and inject some artwork/quotes into locations specified by the content author. This worked fairly well, but it’s always bothered me that our first implementation relied on JavaScript. So if JavaScript wasn’t available, or somehow failed (which we all know never ever happens, no no)—you didn’t get the artwork. We justified that decision based on the fact that the artwork and quotes are an enhancement on the article—the article makes perfect sense even without the random elements.

But still: it felt like it warranted a second pass. I really like how Aaron Gustafson advocates for unobtrusive JavaScript in his book Adaptive Web Design:

“Unobtrusive JavaScript is an idea that meshes perfectly with progressive enhancement philosophy because it forces JavaScript into the role of functional enhancement, as opposed to absolute requirement.”

So this past week we went back to work under the hood, pulling the JavaScript-reliant parts into a custom Drupal module. We did the same things we were doing on the client-side, except now we do them just before we render the page, using some new tricks we learned about selectively replacing markup after all Drupal modules have run. The result is a page that has all its artwork and quotes, even if JavaScript takes a nap. Most people (hopefully) won’t notice a thing, but I’m glad that we’ve continued to move towards a more accessible and inclusive site.

Lapham’s Quarterly

A few dev notes on the recently-launched redesign of Lapham’s Quarterly:

  • The site was designed and built by Bluecadet (with the exception of the online store, for which we only did the design templates). Design was led by Theresa Decker. Will Vedder and Greg Sarault handled most of the development. Kevin Zakszewski did a lot of early responsive prototyping during the wireframe and design phases. Rebecca Smith handled both content strategy and project management (!). I did technical strategy and a few tricky Drupal/JavaScript pieces.
  • It’s a Drupal site. Drupal can be a sprawling beast sometimes, but it was a good fit for this project because of the complex relationships between issues, contributors, and individual articles.
  • We built and deployed the site on Pantheon, which allowed us to open up the CMS to content authors in one tier while we developed/tested on the other tiers.
  • A lot of Lapham’s Quarterly’s content requirements involved some form of what we internally dubbed “sophisticated whimsy” – Essays and Voices in Time on the issue page had to be pulled randomly, for instance. We ended up doing a few compound views to achieve complex layouts.
  • Artwork and quotes that appear on Essays and Voices in Time are not directly related to the piece itself (carrying over a hallmark of the print quarterly). For the website, however, Lapham’s Quarterly wanted the artwork and quotes to also be random, lending the piece a slightly different look each time it was loaded. Content authors choose the point at which they want to insert an instance of one of three types of content: a column-width image, a widescreen image, or a quote. These generate markup patterns that then replaced with a random instance of artwork, pulled from the available options for that issue (each issue has a bucket of artwork/quotes).
  • Each issue that Lapham’s Quarterly publishes has a signature color. In the website’s design system this translates to a set of four hex values to cover different states: default, rollover, emphasis, etc. We wouldn’t be able to treat those colors as Sass variables, since we didn’t want to have to add to the stylesheet each time Lapham’s Quarterly published a new issue. So they are injected at the page template level, based on the values set by content authors for that issue. The styles … cascade.
  • Lapham’s Quarterly needed a way to designate an issue as “Coming Soon”. This meant that any content associated with that issue would not be displayed/linked from the archive pages. We had to write a few hook functions to filter taxonomies prior to display.
  • Handling BC dates turned into more of an interesting development problem than we anticipated, because we wanted to keep the actual date value different from the display, to make sorting content by date easier. We ended up writing a small custom module to transform BC dates for display.
  • There was a lot of iterative design and development for this project. One example is the slide-out tab allows you to get back to the main issue page. That was originally visible at all times, but as we started testing content we realized that it obscured the widescreen images. So we turned it into a little pull-tab.
  • There’s no single workflow technique that emerged from this project, just a general feeling that team conversations around a whiteboard are rarely a waste of time. In most cases we arrived at a faster, more bulletproof solution than if we had sealed ourselves off to work in isolation.

We’re still fine-tuning thing under the hood, but I’m very happy with how the project turned out.