Doing Responsive Typography

Responsive typography makes it possible to serve typographic compositions that adapt to fit their various environments, resizing, reflowing as necessary to best serve the reader, whether they’re viewing the content on a phone, a cathode ray tube, a large display, in print, or something in between. With this piece, we’ll take apart a simple example of responsive typography I made, and see how it works. Adapting other aspects of typography beyond size, measure, etc. is certainly open to further exploration, but I’m keeping this first one simple.

Responsive typography is just typography.

All normal principles apply. The new principles involved deal mainly with being mindful of in-between states—the areas just outside your control. Ready? Let’s go.

Doing-Responsive-Typography-1

Here’s the demo I made.

I started by setting up a development environment on my computer (an Apache web server), and tested on real devices as I went. I wrote the markup and styling (HTML and CSS) in a text editor (BBEdit). And I did a lot of fiddling with the styles in the browser (using Firebug, an add-on to Firefox).

I built out the structure of a two-column layout with the idea that as the width of the page contracts, the right column is hidden. (I could have just as easily turned the right column into a footnote or something.) I styled the page following my own CSS advice: specify as little as possible. In the HTML header, I added this important meta tag:

<meta name="viewport" content="width=device-width"/>

This prevents smaller-screened devices from displaying a scaled-down desktop version of the page. It keeps the text from getting too small. Don’t underestimate the importance of this step.

Set the body font-size to 100%.

Type that’s sized smaller or larger from here should be specified in em units. Since em units change depending on the font-size specified in a given element, you may want at times to refer to the original em you specified. You can. They’re called root ems, or rem units. In the right column, I give the line-height in rem so that I’m able to maintain the same baseline rhythm as the normal body copy. (Since the body’s line-height is in rems, I could have just as easily set the right sidebar’s line-height to inherit.)

Just as an aside, reorienting from portrait to landscape has become commonly understood as a simple way to make the text a bit larger. Some (those with poorer eyesight) are in fact counting on this. So just because you can maintain a consistent text size across different orientations doesn’t mean you necessarily should.

Screen Shot 2013-11-07 at 7.55.06 PM

Give yourself margins.

One common problem with typography on the web generally is a lack of margins. Setting margins to auto works fine until the window or viewport causes that auto value to go down to zero. So in this example, I put an additional 2em body margin outside the content wrapper’s auto margins.

Breakpoints

It’s precisely at this spot where the auto margins hit zero that I place my first breakpoint. More like a transition/squish-point, really. All that changes when the viewport goes down to 52 ems is that the content wrapper goes from a specified 45 ems in width, to taking up 100% width of its parent element, the body. In CSS, that looks like this, just below everything else in the file:

@media only screen and (max-width:52em) {
 #wrapper {
    width: 100%;
 }
}

Screen Shot 2013-11-07 at 7.56.15 PM

As the two columns shrink in size, their text reflows as needed until the right sidebar column gets too narrow. At this point, for simplicity’s sake, I just take it out, and let the main column take up the full width.

@media only screen and (max-width:45em) {  
  #sidebar {
     display: none;
  } 
} Screen Shot 2013-11-07 at 7.57.38 PM And it's that simple.

What’s left to improve here? Well, for starters, I think I could show more variety in terms of type size and webfont specification. Maybe the right sidebar could go up a touch in weight. I could get those baselines to reconcile.  I could demonstrate how to target different screen resolutions differently. Seems like the measure on the iPhone is a bit narrow. And I could definitely do something more interesting with the layout at larger sizes. Maybe add a nav area to show how to scale and selectively show/hide links. There’s really a lot I’ve got left to explore.

I’ll return to this series on responsive design from time to time with demos of stuff I find interesting.

Using Type continues here each Thursday. Thanks to Nicole Dotin’s Elena for setting the nameplate, and of course Michael Abbink’s FF Milo Serif Web for the live demo text.

3 Comments

  1. Posted November 8, 2013 at 2:39 PM | Permalink

    Great lesson, David. I’m wondering if you could touch a bit on the considerations for devices that drop below 400px, specifically with regards to font size and measure. It seems kind of counterintuitive but I’ve been reading about how, with phones and mobile devices, we actually need to make the font size & line-height larger since the text is being read in such a small window. This seems to override the idea of a “comfortable” measure, so it’s somewhat confusing.

  2. Posted November 8, 2013 at 2:49 PM | Permalink

    Hi Casimir.
    I initially designed the example to behave this way, but I found in testing that later adding the meta tag resolved the problem, at least on the sub-400px devices I tested. Did you get different results? Is it coming up too small for comfort?

  3. Casimir
    Posted November 13, 2013 at 8:42 AM | Permalink

    I suppose I’m referring to a less concrete measurement that depends on the size/context of the device you’re using. For example: 16 points is more than adequate for desktop displays, but on tablets it starts to “feel” a bit small, and especially on my iPhone it feels smaller still. I’ve found that for the iPhone and devices in a similar range, I’ve been bumping my font size up to 18 or even 19-20 points, depending on the face. This obviously means I get a shorter measure, usually no more than 31 characters, which by traditional typography rules would be considered much too short for single-column text blocks.

    There definitely seems to be an inverse relationship between the size of the screen and the size of the text properties: As screens get smaller, text size and line spacing need to get bigger, which results in shorter measures. And while a 30-character measure may be too short for print/large screens, it seems to be just fine on handheld devices.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Follow

Get every new post delivered to your Inbox.

Join 61,747 other followers