Responsive Typography is a Physical Discipline, But Your Computer Doesn’t Know It (Yet)

For ideal typography, web designers need to know as much as possible about each user’s reading environment. That may seem obvious, but the act of specifying web typography is currently like ordering slices of pizza without knowing how large the slices are or what toppings they are covered with.

Article Continues Below

Share This:

Job Board

If someone asked me how many slices of pizza I wanted for lunch, I would probably say it depends on how large the slices are. Then—even if they told me that each slice was one eighth of a whole pie, or that they themselves were ordering two slices, or even that the slices were coming from Joe’s Pizza—any answer I might give would still be based on relative knowledge and inexact assumptions.

Such is the current situation with the physical presentation of responsive typography on the web. The information at a designer’s disposal for responsive design is virtually nonexistent outside the realm of software. Very little knowledge about the physical presentation of content is available to inform the design. The media query features of today can only relay a very fragmented view of the content’s actual presentation, and related terms from CSS are confusing if not downright misleading.

The immeasurable pachyderm

Among all the physical qualities of web typography, the elephant in the room is the issue of size. I’m not talking about em or rem or “reference pixels”¹ or even device pixels. I’m talking about real, actual, physical, bona fide, measurable, size!

It’s ridiculous that we can send robots to Mars yet it’s still virtually impossible to render a glyph on a web page and say with confidence: “If you measure this glyph on your screen with a ruler, it will be exactly 10 millimeters wide.” Although actual physical size isn’t always the most important factor in web design, in some cases it is critical. For example, consider content for partially-sighted or low-vision readers: the ability to tweak designs according to physical sizes would enable designers to make conscious design decisions with much more sensitivity to how the type is actually being seen. And even where physical sizing is secondary to relative sizing, why shouldn’t we nevertheless be able to factor in physical size when establishing the relationships between different elements?

Physical considerations ≠ print design

I don’t believe web typography should be a screen-based imitation of print typography. One of the greatest benefits of web typography, and web design in general, is that it is flexible, adaptable, fluidly adjustable, without being locked into any one specific configuration. However(!), that doesn’t mean web designers should be forced to design without any means to address the issues of physical presentation. On the contrary, responsive design will not reach its full potential until it allows the ability to respond to the very important physical variables of digital media.

Please pardon the cliché, but when it comes to typography, on screens or otherwise, size matters. Physical size affects optical issues that change how the eye and brain process typographic images. Not surprisingly, typographers and typeface designers have been compensating for optical size-related issues as far back as Gutenberg.

You can’t expect a paragraph of type with the same relative line-height, column width, letter-spacing, and glyph proportions to function just as well on two different displays that have the same number of pixels but completely different physical sizes. It’s great that designers can adjust proportions between typographic elements if the canvas varies in relative size, but any such compensation is still based on guesswork and assumptions about the physical size of that canvas. When people disagree about the size or spacing of type on a website, there’s a very good chance that their opinions are based on completely different physical manifestations of the same content, even if their software and settings are identical.

Resolute resolution, absolute absolution

One of the most crucial factors in the size equation is resolution. And when I say resolution, I don’t just mean “how many pixels is this?”, or even “how many device pixels is this?”, but also “how large are these pixels?”

This is very different from the W3C’s “resolution” media feature in the current draft of the Media Queries Level 4 spec. You will note that the spec refers to resolution in terms of “CSS ‘inches’”—the quotes around “inches” are theirs, implying that they are not actually inches at all.

For an example of why physical resolution matters, imagine you are rendering text on a digital billboard with a physical resolution of one pixel per inch (1 PPI). Now imagine you are rendering the same text on a 200 PPI mobile device display. Even if you knew the actual number of device pixels that would be used to render your type (which itself is difficult to do with confidence these days), you would want to treat the two compositions very differently, both in terms of the typeface as well as typographic layout. The billboard type would likely require less space between letters. The letterforms themselves would benefit from narrower proportions, and could endure a higher ratio between thick and thin strokes. The type might even require different colors to optimize contrast at that size. These are all basics of typography and typeface design.

Unfortunately, in the current landscape of media query features, there is no way to know the difference between 16 device pixels on a crude LED billboard and 16 device pixels on a high-density mobile display. Heck, there isn’t even a reliable way to know if your type is 16 device pixels at all, regardless of how large the pixels are!

Pixels still rule, for better or worse

I know what some em-based enthusiasts might be thinking: “But you shouldn’t be specifying type sizes in pixel units to start with! All type sizes should be spec’d abstractly in relation to each other or a base font size!” However, in the current world of web typography, no matter what unit of measure you use to spec your onscreen type sizes—em, rem, px, pt, in, %, vh, or whatever else—at the end of the line, your specification is being mapped to pixels. Even if you leave the base size of your document to the defaults and specify everything else with em, there is still a base size which all other sizes will ultimately refer to, and it is defined in pixels.

This is because, currently, the only unit of measure that can be rendered onscreen by any operating system with absolute confidence is the lowly pixel. Until we have media query features that allow us to spec for situations like:

@media (physical-resolution: 1device-pixels-per-physical-inch) { … }

or:

@media (device-width: 10physical-centimeters) { … }

… any compensation for physical size is based entirely on rough guesses about the devices our content will be presented on.²

It’s a complete fallacy that the official CSS spec allows so-called “absolute” units of measure like inches, points, and centimeters to be mapped to anything but actual physical units. Ironically, previous versions of CSS treated these things as you would hope and expect, but a change was made “because too much existing content relies on the assumption of 96dpi, and breaking that assumption breaks the content.” Call me idealistic if you will, but I am more of the mind that a spec should be written based on what is best for the future, not to cater to things that were made in the past.³

Getting physical

Any ability to leverage physical variables for web design will require a joint effort by several groups:

Device manufacturers will need to provide APIs that can inform the operating system—and, by extension, web browsers and web designers—of the actual physical properties of the hardware being used to present content to the user. Some device APIs are already beginning to show up in the world, but there is a long way to go before functionality and adoption are anywhere near dependable.

Standards organizations—the W3C in particular—will need to establish specifications for how to reference physical properties when formatting content. They will need to update (or at least augment) their existing “absolute” units of measure to be more meaningful, so they are more than just multipliers of sizeless pixels.

Software manufacturers will need to implement support for new specs relating to physical media features. Browsers are the most obvious software that will need to implement support, but the biggest challenge might be in getting native support for device APIs in operating system software.

Type manufacturers and type services will need to provide more diverse ranges of typefaces that have been optimized for a variety of physical properties. Ideally, many of the needed variations could even be provided on the fly using a broader approach to the ideas of font hinting.

Web designers and developers, last but not least, will need to build their sites to respond to physical properties, leveraging all variables to the benefit of their users.

Size and resolution are just the tip of the iceberg of physical variables that could be considered when improving web typography. Things like viewing distance, ambient light, display luminance, contrast ratio, black levels, etc., etc., could all be factored in to improve the reading experience. Even the ability to know some variables within the realm of software, like the user’s rendering engine or the presence of subpixel positioning, would go a long way toward helping web typographers design a better reading experience.

In the meantime, I’d love to see more of the players mentioned above start to at least experiment with what’s possible when physical features can be specified, detected, and factored into responsive designs in structured, meaningful, and predictable ways. Until we can do that, we’re all just ordering pizza without knowing exactly what will end up on our plate.

Notes

1. Perhaps it's a lost cause, but I always thought the idea of referring to reference pixels as “pixels” at all is a horrible idea. Not only does it confuse the already complicated issue of sizing, it also completely changes the meaning of one of the few terms in web design that everyone previously agreed upon and understood clearly. As I’ve suggested before, it’d be so much more helpful to coin a new term that can be used without ambiguity when referring to relative size in the physical world. The W3C’s description and illustration of a reference pixel describes a reference pixel as an angular unit of measure (“about 0.0213 degrees”). And don’t get me wrong, this is a great thing! We’re already seeing experiments of how such things might be useful. But why not specify these relative units with unambiguous terms like arcminutes that are already in use elsewhere? Why can’t a pixel just stay a pixel? ↑

2. These imaginary names for physical units of measure are not my official suggestions for adoption. I would much rather change the specification so that px always refers to device pixels, in always refers to actual, physical inches, cm always refers to actual physical centimeters, and so on. ↑

3. Such backwards thinking has left us with many illogical workarounds that might have provided short-term comfort when first implemented in a spec, but remain rooted in modern technology long past their purpose, causing years of unnecessary annoyance for generations to come. I’ll be sure to elaborate on some examples of this in a future column. ↑

19 Reader Comments

More from ALA

Columns

The number of predictions that algorithms can make about us from even minimal data is shocking. Although we’re offered privacy settings that let us control who of our friends sees what, all our information and behavior tends to be fair game for behind-the-scenes tracking. We simply don’t know everything that’s being done with our data currently, and what companies might be able—and willing—to do with it in the future. Laura Kalbag believes it’s time to locate the exits.

Displays that are more tiny than our lowest-size breakpoints require a more condensed range of type sizes. If you don't already have in place a typographic system that can absorb the demands of this new context (watches, wearables, digital sticky notes, whatever), now might be the time to consider it. Matt Griffin was ready for anything because his site was simple and built to be future friendly.

March 19, 2015

From the Blog

It's all about us this week at ALA. From steps to sleep to social activities, we're counting every kind of personal data you can think of. But what's all that data add up to? How could we look at it—and ourselves—differently? In this week's On Our Radar, we ask ourselves—and our self—the tough questions.

That old monitor you've got lying around? Time to put it to work. Susan Robertson reminds us of how important it is to test our designs on older screens and ensure the things we build work well for everyone.

The future is here, for better or for worse—and this week, the ALA staff has been thinking about what that means: for our code (the impending arrival of HTTP/2), our content (publishing on Medium), and the cost of constant noise.

This week, the ALA staff is thinking about color accessibility, the process of building a vocabulary, the current state of web typography, and the lessons we can learn from skater culture. In other words: it's all about inclusion.