A New Responsive Font Format for the Web

Nick Sherman gave a fascinating talk at Ampersand earlier this month which was based on an article he wrote called Variable Fonts for Responsive Design. In both the talk and the essay he suggests that we need a new font format to solve complex responsive design problems:

…the glyph shapes in modern fonts are restricted to a single, static configuration. Any variation in weight, width, stroke contrast, etc.—no matter how subtle—requires separate font files. This concept may not seem so bad in the realm of print design, where layouts are also static. On the web, though, this limitation is what I refer to as the “glass floor” of responsive typography: while higher-level typographic variables like margins, line spacing, and font size can adjust dynamically to each reader’s viewing environment, that flexibility disappears for lower-level variables that are defined within the font. Each glyph is like an ice cube floating in a sea of otherwise fluid design.

Manipulating a character in this way is commonly referred to as interpolation in the type design community: designers pick multiple poles, such as thick or thin, condensed or extended characters, and let a clever algorithm create a value in between. The example below, from Andrew Johnson’s SVG interpolation experiment, explains this process well:

As Nick mentioned, interpolating from light to bold, or from thin to wide letterforms is unfortunately impossible with the current font formats that we have for the web. However, he’s not the only designer calling for improvements to be made here, as Andrew Johnson has made similar requests for a responsive font format:

…today’s webfonts tie our responsive sites and applications to inflexible type that doesn’t scale. As a result, our users get poor reading experiences and longer loading times from additional font weights.

But why would we want responsive features like this in a font format anyway? How would that help us solve design problems?

The benefits of a variable font format

This new format would offer minute typographic control for designers, particularly for when a regular weight looks too thin and a bold weight looks too thick. Instead, we could pick a value in between thin and bold and the font would interpolate between them — in other words, designers would be able to make a substantial improvement to legibility.

Also, we could finally make layouts where words or sentences take up the whole space of its parent container, just like in the demo called Font to Width:

This technique might sound similar to FitText or using viewport units to set responsive text, but there is a clear distinction to be made that the type designer Erik van Blokland outlined:

Width variations will have an immediate application in fitting typography to the target rectangle. Words need to be able to respond to the page geometry.

So in order to best respond to the “page geometry” we need more control over the fonts that we apply to our designs and the width of each glyph is just as important as being able to set a responsive value for the font-size.

Another reason for implementing a new variable font format might be performance, as we’d only request the download of a single file, rather than the multiple fonts we need today when working with systems that require large type families that contain Extra-Light, Light, Regular, Medium, Semi-Bold, Bold and Black variants.

This idea of a responsive font format isn’t new and there have been multiple attempts in the past of creating something very similar. Adam Twardoch, the Director of Products at Fontlab, called for a resurgence of these ideas back in 2013:

In the web context, I think at least one of these variable font models deserves resurrection – because it offers tremendous compression potentials, lends itself well into the “responsive web” paradigm, offers new possibilities for text layout on the web and, above all, can be implemented much more easily on the web than it ever could be on desktop platforms.

Nick continued to summarise the benefits like this:

A variable font would mean less bandwidth, fewer round-trips to the server, faster load times, and decidedly more typographic flexibility. It’s a win across the board. (The still-untested variable here is how much time might be taken for additional computational processing.)

However, there are lots of technical considerations to think about when introducing a new font format to the web, so how might we implement these features in our designs?

How this new format might work in CSS

In his talk, Nick suggested a practical example in CSS that I’ve developed a little here with an imaginary property called font-width that lets us set the width of a character just like we can set the font-weight of an element today:

@font-face {  
  font-family: WebFont;
  src: url('webfont.new') format('new format');
}

body {
  font-family: WebFont;
  font-weight: 450;
  font-width: 200;
}

h1 {  
  font-weight: 600;
  font-width: 999;
}

We could then set another element to have a font-weight of 601 or 411 or whatever value that the design required for that particular element and the text would respond in kind.

Now, there are most definitely flaws in the example above, but I think it gets to the heart of the matter which is that our websites would be capable of so much more subtlety and nuance than they currently possess. And I can think of lots of examples where this new format would create more striking and beautiful layouts, not to mention how useful it might be in zoomable user interfaces.

What about WOFF?

There’s another font format that’s currently gaining traction called WOFF 2.0. It’s been designed to greatly improve the compression algorithm over its predecessor and it’s going to be wonderfully useful for Asian scripts and other languages that require fonts made up of lots of glyphs. However, WOFF 2.0 still doesn’t give us the design variation that we can get from a variable font format as we still need multiple fonts for different widths and weights.

So I think WOFF is great in the short term, but it doesn’t really help our long term goals of making these font formats truly responsive.

Potential problems

As much as I’ve discussed the advantages of this new format in terms of design and development, there are problems with it, too. Here are some of the most pressing issues that I’ve come up with so far:

• If this interpolation algorithm is running client-side then it’s fair to say it might be bad for performance.
• Licensing web fonts would need to be reconsidered since customers now only need a single font file instead of the multiple weights and widths that they need today.
• Playing devil’s advocate here for a second: but is it really necessary for type to be dynamic on the user’s device?
• I’ve talked to a couple of designers about this and they’ve mentioned that a half-working proposal in browsers would be worse than nothing at all.
• Type designers would need to figure out how to educate designers why this new system might help them in their work and what benefit it has for the web overall. I spoke to a type designer recently and he mentioned how he avoids adding OpenType features into his fonts, such as small caps and ligatures, because so many graphic designers simply don’t know and/or care about them.
• Likewise, type designers can’t easily redesign existing typefaces to use these new variables as they would have to be designed from the ground up to use this technology from the very beginning of a project.

Summing up

I think there’s huge potential for a new variable font format to become a key part of the designer’s tool belt. It would greatly improve the reading experience of general users of the web, too. But that doesn’t mean we can ignore the many problems and hurdles that we have to overcome to get a draft spec agreed upon.

What do you think? Would you welcome variable font files with open arms? Or is the whole idea an idealistic pipe dream? We’d love to hear what you think below in the comments.

Related

• Thomas Phinney’s talk on the history of Multiple Masters and why they failed
• Erik van Blokland’s responsive vector example
• Apple’s abandoned format TrueType GX