How To Maintain Readable Type In Responsive Design

Setting type involves choices that create proportional relationships in your text. Done well and your text will be both easy and desirable to read. As responsive layouts adapt to varying screen widths, one of these choices (line-length) changes. To maintain the same proportional relationships other aspects of the type need to adjust.

Unfortunately the best solution to maintain proportions is not always clear. Some might even question if we should. Throw in the different device resolutions that have come to market and we’re looking at another set of issues.

Forge at the Finkl steel mill in Chicago

Proportion, Scale, and Molten Leading

The most obvious change that comes with responsive design is how layouts change over different widths. That directly affects the measure of our text.

A few months ago Tim Brown raised the idea of molten leading (or fluid line-height). As Tim points out in the post there’s a fundamental triadic relationship in setting type.

  • font-size
  • line-height (leading)
  • line-length (measure)

Adjusting one of the above requires adjusting the others to maintain comfortable reading. Our layouts force a change in line-length and we need to make further adjustments to maintain proportions.

If we increase the font-size of our type, the line-height will scale with it, as the latter is set relative to the former. In some cases this is what we want, but in others it’s not a pleasant experience. Imagine flipping your tablet or phone between portrait and landscape and having to adjust to a new font-size with each turn.

Better would be to adjust line-height with the change in line-length, except line-height is relative to font-size, while line-length here is relative to the widths of our layout. How can we get one to change in response to the other.

Liquid gold being poured

As Tim says we need a fluid way to set the line-height. Ideally we’d be able to set min and max line-heights, similar to how we set min and max widths. In his words

Molten leading would maintain a specific font-size while adjusting line-height based on width.

Tim offers a formula for calculating the line-heights in between the mins and maxes.

line-height = ((current width − min-width) ÷ (max-width − min-width)) × (line-height − min-line-height) + min-line-height

Aside from not wanting to do the math sometimes we can’t easily determine some of the values needed. Fortunately a couple of smart people offered Javascript solutions to both the problem of determining the values and doing the math.

Matt also provided a demo of his solution in action.

Whether you use either method or not, at the very least take away from this section the idea that one of the three type triads is going to change and you must account for that change to maintain readable proportions.

Lowercase 'a' shown in typographic scale

Graded Fonts

Above I mentioned how different devices are now shipping with different pixel densities. Think retina display. A font designed for a low resolution screen breaks down when viewed on a high-res screen.

Oliver Reichenstein from Information Architects talked about this as a reason IA is experimenting with graded fonts or fonts that can adapt to different resolutions. Oliver points to 3 rules of thumb for conditions.

PC — System fonts look fine, though custom fonts need hinting

OSX — System fonts look good at low res and ok on retina displays, however they’re too bold at high res. Lighter fonts look great at high res, but too light on retina displays.

iOS — System fonts look too bold at high res and ok on retina displays. For perfect html performance on retina displays you need a bolder font in portrait and a regular weight font in landscape. For perfect html performance on high res you need a lighter typeface.

Considering the above as a guide you need 3 grades of fonts once you’re outside the PC world and move beyond low resolution screens.

  • light — for high resolution screens
  • regular — for retina landscape in html mode
  • bolder — for retina portrait in html mode

IA designed a custom typeface they’ve named iABC in order to test the above. Graded fonts alone don’t make for responsive typography and won’t absolve us from considering how typographic parameters change across devices, but they can become part of the solution and could easily become more common in the near future.

The words 'Type Size' printed in a book to demonstrate kerning and letterspacing

Solutions for Specific Responsive Type Problems

The sections above discuss two main problems we’re facing. In researching this post I collected resources to more issues that crop up, along with solutions to those issues.

Fit to Scale — Trent Walton wanted to have fine-grained control over typography, the kind of control where he could style individual letters uniquely. CSS gives us things like :first-letter and :last-letter, but not a lot more. One of his partners at Paravel, Dave Rupert, created the jQuery plugin Lettering.js. Dave explains how it works here.

So far so good, but where responsiveness was concerned Trent worried if it would scale. Dave came back with FitText.js to take care of the scaling problem. You can see both plugins in action in the main post headings on Trent’s blog.

Even better, we might be getting a css solution soon. Chris Coyier recently posted, Viewport Sized Typography telling us about 3 new values for sizing things relative to the viewport.

  • vw — (viewport width) 1vw = 1% of the viewport width
  • vh — (viewport height) 1vh = 1% of the viewport height
  • vmin — (viewport min) 1vmin = 1vw or 1vh, whichever is smaller

These 3 values essentially do what FitText does to make type fluid and if you think way back to the top of this post, they allow us to tie the width of the viewport to the line-height. The one downside is these values aren’t yet ready for prime time. They work Chrome 20+ and IE10+, but that’s about it.

It should be pointed out they aren’t just for fonts. These are measurements that can be used with anything.

'Twenty-Fifth' carved into the sidewalk

Hyphens and narrow columns — Sometimes a text column in a responsive layout becomes narrower than some of the individual words in the text. Because of the lack of hyphenation in web browsers this can lead to some less than pleasing results.

A solution is to combine 2 css properties, word-wrap and hyphen.

{code type=css}
word-wrap: break-word;
hyphens: auto;

The first breaks the word and the second adds the hyphen. The downside is hyphens don’t have great support at the moment. In fact to use it now you need to use vendor prefixes for the browsers that support it.

{code type=css}
word-wrap: break-word;
-webkit-hyphens: auto;
-moz-hyphens: auto;
hyphens: auto;

Minimum paragraph widths — Another solution for when narrow columns interfere with the flow of text is to set a minimum width on paragraphs. You can read about the full solution here. The final code ends up being

{code type=css}
p:before {
content: “”;
width: 10em;
display: block;
overflow: hidden;

iOS orientation — This issue is specific to Safari on iOS. A bug allows zoomed pages to scale beyond the width of the viewport when switching from portrait to landscape. The most common workaround has been to disable zooming, but that’s not a great option.

A better solution uses the device’s accelerometer to determine when the device is switching orientation. It temporarily disables zooming until the change is complete. There are a couple of slight issues with this fix that you can read about here.

Maintaining vertical rhythm — If you like using a baseline grid to give a vertical rhythm to your type, you may have discovered that where responsive design is concerned there’s a problem. As images scale with the layout they fall off the grid.

This Javascript solution determines the current height of the image and then adjusts the bottom margin of the image so that anything after falls back on the baseline.

Typographic design of the word 'typography'


As you can see there are some issues in regards to your type responding with your design. The main thing to keep in mind is that good typography requires proportional relationships for comfortable reading. As our layouts change, line-length changes with it and we need to adjust other type parameters to maintain proportion.

Another issue we’re facing is the different pixel densities seen across devices. This is likely to get worse now that Apple has introduced retina display to their devices. Others will follow, though not necessarily using the same pixel density. Graded fonts are the current attempt to allow our typefaces to respond.

Beyond these two issues are a variety of specific problems, each with potential solutions. One of these, viewport relative measurements, might be the answer to the question of how to maintain proportions.

More than anything what I hope you’ll take from this post is the idea that we need to think more about type in responsive designs. We can’t just set everything once and assume it’ll always be fine. Changing layouts and different devices will force type changes on us and it’s up to us to ensure we respond in kind.

« »

Download a free sample from my book, Design Fundamentals.


  1. I’ve been thinking about this too since I read the post in this blog about modular scales in typography.

    I don’t like all these js solutions and polyfills. Where does it end?

    One solution I keep trying out is what they used to call hydrid lay-outs. One fixed column (with ‘perfect’ typography), the others liquid. That and using more breakpoints in your media queries.

    • I hear you about all the polyfills. I’m not a big fan of them either. I think they have a place, though. Sometimes you want to achieve something and a polyfill is the only way. Where it becomes a problem is when you’re using them for everything. In that case I’d ask do you really need to achieve that thing you need to achieve or is there perhaps a better design solution?

      Having a single fixed column can work. I prefer having everything in the layout be flexible since it opens up more possibilities for rearranging your content.

      I also think less breakpoints is a better goal. Right now we can safely design for a handful of screen widths. In the future we won’t be able to. There are going to be more and more devices with ever great differences in characteristics. It’ll become impossible to try to get in breakpoints for all of them. If you set breakpoints based on the content itself, it offers a more flexible solution that typically works across a greater variety of devices and device characteristics.

Leave a Reply

Your email address will not be published. Required fields are marked *