What the web wants

[Spoiler alert: it’s you, and your variable fonts]

I wrote a bit about this in my ATypI wrap-up, but felt this was important enough to revisit. While there are certainly reasons for type designers and foundries to be circumspect about another attempt at a flexible font format (see: Multiple Masters and TrueType GX), I’ve always felt strongly that the time is right for variable fonts because we’re now in the age of the web. This latest iteration of the idea has come at a time when the technology fits needs across the spectrum from performance to user experience to accessibility, and its capabilities bring a dimension to design for digital platforms that has never before been attainable. 

As is often the case with anything new, however, real life can get a little messy. The OpenType specification that defines how variable fonts are created is purposefully, well, open. And with the number of variable fonts created still being relatively low, odd corners of the spec—and their implementation on the web—are still working themselves out. But given that variable fonts are picking up momentum on the web far faster than in print (where support is still in its infancy) it seems worthwhile to talk a bit about choices that would make adoption easier and more likely to spread.

Drop in & just go

The first two topics to cover go together as part of an ‘adoption friction reducer’ dynamic duo: compatibility and performance. In web terms, compatibility means being able to drop a variable font into a site without having to make changes to the site styles. For that to work, the defaults for width and weight in particular must conform to what the web expects and how the site has been coded. Let’s look at those first.

Weight for it

The specification only stipulates two things with regard to weight: that the range can be anywhere between (and inclusive of) 1-1000, and that whatever the type designer deems ‘regular’ must map to 400 (relevant page of the weight axis spec here). This fits with how CSS behaves quite nicely, since browsers actually treat a ‘font-weight’ value of ’normal’ as an alias to a numeric value of 400—and has done so for a very long time. What this does not solve for is ‘bold’, which is similarly an alias—this time for 700. So rightly or wrongly, if a type designer wants their notion of ‘bold’ to line up with the web’s expectations, that needs to fall at 700 on the numeric scale. This of course is up to the type designer’s discretion, but if the best decision for the typeface is to declare that ‘bold’ is more like 625 or 750, it’s important to document that and provide good example code to support it.

For weight, ‘regular’ must be 400 on the weight axis

For a typeface with a weight range of 150-975, we would define that in the @font-face rule like so:

@font-face {
...
  font-weight: 150 975;
...
}

This tells the browser should a lower or higher font-weight value be encountered, it should clamp to the lowest or highest values supplied in the original rule. So long as the ‘regular’ weight maps to 400, default text will look exactly as expected. Should the desired value for bold differ, it can be addressed by redefining a font-weight specifically for elements that should have the heavier weight.

We can then set the weight axis with standard CSS:

h2 {
  font-weight: 825;
}

Stretch-to-width

First, an apology. The CSS property ‘font-stretch’ to denote width was introduced in 2013, long before that property could be put to use in a practical way on the web—and likely before input from the type community. No idea why ‘stretch’ was used instead of ‘width’, but sadly very difficult to change. Sorry—but know that significant efforts are being made to avoid things like this going forward. For now, we have to work with ‘font-stretch’ as the CSS property to access the width axis in variable fonts.

For width, ‘normal’ must be 100 on the width axis

Here, the specification is relatively sparse as well: it calls for the value range to be greater than zero, but there is no maximum given. The second stipulation is that ‘regular’ must be 100 (both clearly articulated in the specification here). This is likely because other associated specifications deal with width as a percentage of normal (i.e. 100), but also fits neatly into how CSS has defined the property. The default value is 100%. when declaring the @font-face rule for a typeface with a width axis range of 60-140, we denote the range like so:

@font-face {
...
  font-stretch: 60% 140%;
...
}

This tells the browser should a lower or higher width value be encountered, that it should clamp to the lowest or highest values supplied in the original rule. And equally important: without specifying anything more, the browser will render text at the normal width. Having seen width ranges varying from 3-5 to 10-400 (with ‘normal’ at widely different values) we’re all at risk of some very unpredictable results, and a disjointed and frustrating experience for web teams trying to implement them.

Again, we can then the width axis with standard CSS:

h2 {
  font-stretch: 85%;
}

The advantage with these approaches is that even if the variable font fails to load, the browser will have some idea how to  render the text as 'bolder than regular’ or ‘narrower if available’—which would not happen if width and weight are set using ‘font-variation-settings’.

Formatted for fast

The performance part of the equation is also in two parts, but they’re truthfully part of the same issue. Variable fonts are often made available only as ’ttf’ files, as those can be used in both print and web applications. But that file format is not well compressed, so the files tend to be large by comparison to what is usually served on the web. Support of variable fonts came along well after the adoption of the woff2 format, this is by far the best option when delivering variable font files on that platform. 

For use on the web, ‘woff2’ should always be available (and is the only format needed there)

And since the first objections we tend to encounter when introducing fonts on websites center around performance (how much data is downloading, and how fast will the page show up on the user’s screen), the better compression of the woff2 format is essential to overcoming those objections.

The other common scenario with variable fonts is having the entire available character set in that one file. Like with the ‘ttf’ format, this may be ideal for use on the desktop, it is generally not how web teams go about optimizing the experience on their sites. Most font vendor sites tend to offer subsets by character set (like Latin 1 Extended), allowing the designer or developer of the site to choose the font files that will support their language requirements with the smallest possible font files.

To have any chance of overcoming performance objections while gaining the design flexibility the format affords, it’s vital that variable fonts be made available in the format (woff2) and language subsets that web teams need. Otherwise the new format will never take the lead. Worse, it’ll never get off the blocks.

Can it work?

It’s a fair question, and one that has been much debated over the past three years: can a variable font be small enough in comparison to collections of static single-instance web fonts to ‘win’ a performance comparison, and compatible enough to not require changes to the rest of the CSS (beyond calling the variable font in the first place)? Well, turns out that no matter who believes what, the answer has been empirically proven by Google and one or two other projects over the past few months. 

• As I wrote in the previous newsletter, the Google Fonts team undertook an experiment whereby they started serving a variable version of Oswald on sites where there were enough instances (different weights) in use, and for site visitors using browsers that support variable fonts (which is now pretty much everything except Internet Explorer. Even the new Microsoft Edge browser has been on board with them for a couple years). In those circumstances, Google Fonts served the variable version to the tune of over 148 million times a day, without any of the site owners having to do a thing. Their CSS just worked.
• In the project I worked on for the State of Georgia, we reduced the font load by using Source Serif Variable instead of the static version for supporting browsers as well. All while safely delivering the static ones for all the state employees, who at the time of this writing are still using IE11.
• Another case came up last week: a major sports broadcasting site is using 4 instances of a commercial font and 3 instances of an open-source one. Looking at the available variable versions, the total font download could be reduced from 370kb per page to 100kb, with a corresponding reduction in font requests from 7 to 2.

Will this always be true? Certainly not. The more axes within a given font, the larger the file will be. But there will be times when that’s worthwhile. When balanced with other resource decisions on a site, they can still deliver very strong design and experience value for the download required. But it’s equally clear that in many cases, it absolutely can be an empirical ‘performance win’ _and_ a design one.

But we want to do more than just replace static fonts with variable ones

That may be a benefit in some instances, but by itself doesn’t push design or the web forward. Besides the more standard weight, width, and italics (and/or slant), there are at least two other axes that could play a big part in their adoption.

Design, redesigned

Once we have variable fonts in place, we can bring better typographic sensibilities to bear—and start to make use of widths and weights in more sophisticated ways. I’ve written a fair amount about that, and there’s ample precedent in print design (from which we have _so_ much we can learn). I think those axes alone give us the tools to completely transform design on the web as we know it.

But adding optical size can help make typefaces even more legible (and beautiful) at an even wider range of sizes. Roslindale in its variable form, from David Jonathan Ross, shows this to great effect on my site: it’s got loads of contrast and fine details when set for headings, yet is sturdy and readable for body copy as well. Portada from TypeTogether is another fantastic text face with optical sizing. You can see that in use on the Ad Hoc blog, another recent project. I covered optical size in more detail back in May, and really hope we’ll see more typeface designs with this axis in the future.

The other axis that has a lot of promise in several areas is grade. The notion of ‘grade’ goes back many years, and was first pioneered in several designs from Font Bureau in order to vary the ‘color’ of printed text and compensate for press and paper quality and help create a more uniform final output. Grade can be described as subtly altering the weight of a typeface without altering its metrics, or the physical space the typeset copy occupies. That means small alterations of grade won’t reflow your text. 

On the web this can be useful as an accessibility aid to create a stronger contrast between text and background for users with low vision, or to make text more readable in inverse-contrast color modes (think: the new ‘dark mode’ in the latest iOS, also available on other platforms). It can also come in handy when designing interface animations to add an extra dimension to various color effects without worrying that the type will reflow. The recent Open Source variable offering Roboto Delta from Type Network is a good example, and I have a demo of light/dark mode using it here.

We all need to show up

There are more variable font offerings showing up on a regular basis, which is incredibly exciting. But there’s still a long way to go in creating enough awareness and examples to really jump-start adoption. While there are a few individuals who have devoted a substantial amount of time to writing and speaking about them at conferences and workshops over the past three years, there have been few signals until recently from the bigger companies responsible for the introduction of the format in the first place. 

There’s support for variable fonts in Illustrator and Photoshop from Adobe (now in beta in InDesign), but that has been buggy and slow to progress. In the past few months there have been some real bright spots with the introduction of a number of variable fonts from Monotype, and the inclusion of them a others on Fonts.com and elsewhere; and more recently Google made some huge announcements at ATypI Tokyo: the use of Oswald was big, and they introduced the new variable font Recursive (designed by Stephen Nixon), and previewed the beta of their new Google Fonts API with support for variable fonts (which I covered a few weeks ago). Another unexpected bright spot is the latest release of the design tool Sketch includes support for variable fonts that seems to be working nicely.

One of the most visible and significant efforts in the web development world is from the team at Mozilla: not only have they created some incredible developer tools for working with fonts but Jen Simmons has also produced some fantastic videos showcasing how they work.

These are welcomed signals of support, but we need more, and we need it where designers and developers are looking. That means promotional and educational content at the point where fonts are being selected and acquired: right there in the Google Fonts UI, featured on My Fonts and other purchasing platforms, and in the Adobe Fonts interface as well. Of course, they also need to add support for variable fonts in the platform itself. I know there are efforts underway at Adobe in the area of font development, but as one of the core members of the group that introduced the format, I don’t think it’s unreasonable to ask for more visible support and progress.

As for foundries and designers who have introduced variable fonts, you are certainly to be applauded for jumping in and making things. But that has also been followed by some voices expressing frustration about lack of sales. Which of course is frustrating.

But that’s not surprising

Without marketing, simply making a variable font available (and in many cases, only with the purchase of a full family) will likely never amount too much. Customers need to know what the format is, why it matters, and what they’ll gain by using it. But the most effective marketing is likely going directly to some existing customers, showing them some concrete improvements that could be made, and offering them a deal to try it out. 

That may benefit from working with a partner who knows the web and the implementation side of things, but there are a few of us around who fit that description and any of us would love to help. If the customer chooses to ask for help in that implementation, great: that’s up to them. The only significant cost to the foundry or designer will be whatever concession they choose to make with a license in return for having a case study to showcase on their own site and with other customers. Through this kind of partnership between the foundry, a web-savvy partner, and the type client themselves—everyone can benefit, and a market will be made.

It’s beginning

A few foundries and font vendors have reached out, and inquiries are starting to become more and more regular from agencies and organizations. It’s really gratifying and exciting that these are happening almost every week. And by no means am I the only person who can help. But building up from a trickle to a tide will take more streams together. Keeping the specs in mind (both OpenType and those for the web) will greatly ease adoption. And showing clients clear benefits in both concrete and aspirational terms, with tools (like documentation and code) and partners available to help, will turn the faucets wide.

The web is waiting

Let’s work together and answer the call. The future of design and typography will be built on it.

Resources

• Oswald Variable demo on CodePen (using the Google Fonts API)
• Loads more web typography demos on CodePen
• Follow Nick Sherman’s VariableFonts account on Twitter to stay up-to-date on news and new releases