Variable fonts & the future of web design

Our state of affairs

The current state of design on the web is stalled. We made a huge leap forward with the widespread availability of web fonts starting in 2009, and then were confronted with the advent of responsive design just a year or two later. While many interesting things have come from that evolution, we’ve also struggled with coming to grips with the complexity of designing for infinite screen sizes whilst being equally concerned with performance. Contending with ever-shortening attention spans (Google research gives you about 3 seconds before you lose half your audience) we’ve had to constrain our typographic systems to just a few fonts to keep the impact on load time to a minimum.

Demo page overloaded with 18 web fonts

These constraints have forced us as designers to make compromises when considering type size, line length, and overall visual hierarchy and differentiation. Considering things like a narrower font on smaller screens to achieve a slightly longer line length without sacrificing size. Or utilizing ultra-thin or ultra-heavy weights for added emphasis and variety of expression — all luxuries we can’t embrace due to the burden it would place on site visitors — particularly those on shaky wireless connections.

Evolutions in layout systems for the web like Flexbox and Grid are coming along, but with only incremental improvements in compression of font formats, we’re left wanting for more freedom of expression through greater variety of type. The demo page I’ve created has been designed purposely with every weight of Roboto and Roboto Condensed available through Google Web Fonts. The goal is to showcase the variety of typographic expression that can be achieved with only width, variant, and weight.

A sea-change on the horizon

On September 14th, 2016, at the ATypI conference in Warsaw a curious collection of representatives from Adobe, Apple, Google and Microsoft took the stage to announce the new evolution of font format known as OpenType 1.8. With that came the demonstration of central showpiece of the release: variable fonts. There was much rejoicing, and no small amount of jaw-dropping and applause. While this is undoubtedly a huge thing for type and type design, the implications for the web are only just beginning to be understood.

I’m just going to say it:

This may be the most significant development for design on the web since responsive design itself

The video above shows a demonstration of some of the possibilities from within FontLab (thanks to FontLab’s Thomas Phinney for tutorial and software!)

Allow me to elaborate. Type is the voice of your words. If we can only use a limited set of weights and widths, we have a limited range of that voice. So our ability to modulate that voice is extremely curtailed. The power of typographic range is multiplied when we can expand that range from 3 or 5 or 6 fonts to 10 or 15 or more, and that range is what amplifies our message. With that, even a static design can achieve much greater differentiation of hierarchy and contrast. Extend that to responsive designs and it’s even more significant.

With the ability to respond to device capabilities via media queries, our ability to match typography choices to device context is finally a reality. We can tailor the width and height of characters for greater legibility and readability on every screen. Lower pixel density? Increase size and x-height. Higher pixel density displays like the iPhone can get a more refined scale, perhaps a bit narrower for slightly longer line lengths. Headings can scale down a bit and get narrower for even better word wrap on small screens. All without requiring an additional asset.

I’ll be honest: it’s not really figured out all the way yet. We won’t know for a little while exactly how well we can do with file compression given all the additional data that will be included. But even if a single variable font file is several times the 20–30k of a single weight it won’t be any worse from a performance perspective, and the design possibilities are exponentially greater. And performance improvements in compression only get better, so even that’s a shorter term issue.

So let’s give this a try

Weigh in on the evolution of the specification on GitHub (I promise, it’s basically a message board and not that difficult to navigate). Get to know the demos (there’s a few down below) and we can get back to designing, not just making squishy boxes.