Variable Fonts from a web design perspective (podcast)

Chris D

I came across this great episode discussing the impact that variable font technology will have on web design in 2018 and beyond. Some very interesting perspectives are discussed: 

https://shoptalkshow.com/episodes/296-variable-fonts-jason-pamental/

Discussion starts around the 2 minute mark.

Link to the book featured, "Reponsive Typography: Using Type well on the Web", Jason Pamental (O'Reilly) 
http://rwt.io/resources/books/responsive-typography-using-type-well-web

Kent Lew

During the past year or two, Jason has been a fairly regular fixture on the schedules of various type conferences (ATypI, TypeCon, et al.) speaking about this topic. You may be able to find online videos of some of these talks from these organizations as well. He is an engaging presenter.

Chris D

Nice. Thanks for the heads up! The podcast did mention his attendance at TYPO etc. in recent years incidentally.

jeremy tribby

it's been my experience that it's hard to sell dev teams on responsive type because it's a bunch of network requests with a considerable payload size. VF drastically reduces both which essentially nulls the argument against. I'm excited for this new era as people (and browsers) catch on. I think Safari and Chrome are there, Edge is about to be (or is?), Firefox a little behind, but by global numbers (per caniuse.com) we're at 61% support?

Johannes Neumeier

I agree with @jeremy tribby. Type designers focus so much on the design space implications of variable fonts, but I imagine the driving force for adaptation is and will be simply the performance gain and complexity reduction on the web.

John Hudson

Type designers focus so much on the design space implications of variable fonts, but I imagine the driving force for adaptation is and will be simply the performance gain and complexity reduction on the web.

The two are closely interconnected: the performance gains are dependent on what the type designer does in the design space.

Cory Maylett

jeremy tribby said:

it's been my experience that it's hard to sell dev teams on responsive type because it's a bunch of network requests with a considerable payload size.

I'm not sure I totally agree. With network speeds getting increasingly faster, bloat has more than eaten up the faster transfers. 

Twenty years ago, we'd squeeze out every byte from the HTML and the images. Some of us still make an attempt, but it's getting increasingly difficult. Today, most web pages are burdened down with hundreds or thousands of lines of HTML, CSS, Javascript, SVG and huge images that have hardly even been optimized. Tossing a few fonts into all that typically amounts to just another fraction of a second of wait time for that first page to load.

The exception is mobile, which accounts for over half the traffic on many websites and is still relatively slow. Most of the recent websites I've built call in a few extra fonts, but I'll typically strip all but one or two from mobile resolutions. Half the developers I work with, though, don't even worry about it there (although they should) The other half seem fanatical about it.

Roel Nieskens

I imagine the type of developers who use unoptimised images in their projects will indeed not be impressed with the performance gain of variable fonts.

@Cory Maylett How do you determine when to drop fonts for mobile?

Cory Maylett

Roel Nieskens said:

How do you determine when to drop fonts for mobile?

I suppose the main reason for pulling in additional fonts is to help create a unique personality for the site.

There might be one typeface that's critical for maintaining this brand identity, so I'll tend to keep that one while reverting to system fonts for those instances of lesser importance at smartphone resolutions.

Roel Nieskens

@Cory Maylett I'm sorry, I didn't mean the reasoning so much as the technical solution you used. The problem with resolution is that it doesn't say anything about whether the device is a 5" smartphone or a 32" monitor, so you might show system fonts on a high-end desktop computer connected over fiber, and downloading all the webfonts to a high resolution mobile phone on slow 3G.

A nicer solution might be the CSS font-display property when it gets better support, where you show the page immediately in a limited set of fonts, and load the rest of the fonts in the background so they can be used on the next page. Your content will be available a.s.a.p. and nice webfonts only on subsequent pageviews.

But at this rate variable fonts will get support just as soon, and I personally much prefer an ideal solution for the majority (lots of variants with variable fonts), and a good fallback solution for the rest (single regular webfont or even "system fonts").

Cory Maylett

@Roul Nieskens Sorry, my bad. I misunderstood your question.

I doubt there's currently a surefire way to handle the problem. This might be an issue mostly confined to the group of developers I work with, but they're using variations of what's found here: 

https://css-tricks.com/preventing-the-performance-hit-from-custom-fonts/

Supposedly @font-face only downloads a font if the font is actually used on the page, so a media query for width or device-width can be used to load additional fonts for larger devices. Whether this is true for all browsers (especially IE), I don't know. The guys I work with claim it works with most, so I use it. JavaScript might be a surer thing, but I've run into the text flash problem doing it that way. But I mostly confine myself to front-end work, so the finer points of scripting elude me.

Roel Nieskens

You can indeed tell the browser when to apply fonts and when not to through media queries. The problem lies in trying to find out whether a visitor would be better off with all fonts, or with a small subset. If your media query says "everything below 1000px is considered mobile", then lots of high resolution mobile devices will not be caught with that media query. The bigger iPhones and many regular sized Androids have a minimum resoltion of 1080.

Ideally we want a "is this user on a slow connection", or a "is this user on a small screen device" media query, because that's the real question we want answered. But because we don't know, I think the whole "serve small, modern variable fonts to those who can use them, and a limited amount of small, old-fashioned fonts to the rest" philosophy best deals with these unknowns.

(I guess I belong to the fanatical half!)

Cory Maylett

Yeah, but that's largely true of delivering most responsive content. You aim for a sweet spot somewhere in the middle that's targeted at most users while making it easy for those on either side of the bell curve to adapt to what's being served.

I typically keep the content and layout more or less the same for widths over 750 pixels. When the display widths decrease below that, I'll make significant changes to the layout and downloaded resources with the assumption that it's likely a smart phone requesting the page. For those coming in on mobile devices with a higher pixel count, well, it might not be ideal, but they're at least used to dealing with both the pros and cons of their higher-end equipment since so many websites are built using the same philosophy. 

We're probably heading off on a tangent unrelated to either typography or variable fonts, so my apologies for that.

John Hudson

For the record, Cory and Roel, I find this tangent very interesting, and suspect other font makers will also. Many of us lack insights into the concerns of web developers or their methodologies.

Roel Nieskens

I think the difference with responsive layout and webfonts is that a layout is made malleable to fit any sort of screen, and you let each device sort out which layout it needs to draw. As a developer you create the layout and instructions by which a device can decide what to draw, and you send that to each device. They all get the same "package" and there's no real difference in performance.

Webfonts are different in that you have to decide up front which fonts will have to be downloaded by the device, and what needs to happen when the fonts are still being downloaded, or if they fail to download. In theory, every device will blindly follow those instructions. Any downloaded asset will impact performance, but you can't instruct a device to only download the fonts when the performance impact is low (e.g. when you're on a fast, low latency network).

A good way to deal with that is making your site work without any webfonts first, by having good fallback fonts. You've covered old and exotic browsers, those with tight security settings, those who have webfonts deliberately turned off, those who're on a slow wireless connection, those who's connection dropped because the train just entered a tunnel. With the bottom line in place, you serve webfonts to the rest: any browser that can handle WOFF or WOFF2, which is basically "every modern browser". You might even only do WOFF2, if you decide to put Safari on El Capitan and older, earlier versions of Edge and a few smaller mobile browsers on the Old Browsers list.

By drawing the line in the sand at WOFF2,  the biggest chunk of browsers get the proper fonts, the rest a nice fallback.

At least, that was the case until variable fonts. Only serving fonts to browsers with variable font support is a bit too premature today, but will become a good place to draw the line in the sand soon. Then we'll get to a situation similar to that for responsive layouts: you just send one "package" over the line, the same for all devices, and the device will use weights, widths and other variants as instructed.

As side note, specifically loading webfonts based on resolution: I'm waiting on the train, reading an article on my phone in portrait mode that loaded just two webfonts. I move to let someone pass, in the process tilting my phone slightly so it goes in landscape mode, triggering a media query to fetch six more fonts. Unless deliberately accounted for, the text in those six fonts will either transform to a fallback font, or worse: become invisible until these six new fonts have trickled in over the crappy 3G connection.

@Cory Maylett Please know that I'm not trying to argue or be pendantic — I just really love this subject and like to talk with others on how they approach certain problems. It's a great way to get your theories in order, and tested!

Johannes Neumeier

A good reason for designing and testing with font fallbacks is also this: Tracking blockers like Ghostery prevent web font download from places like TypeKit. Web fonts served via CORS are also a privacy concern, because the serving of web fonts can be seen as tracking a user across different websites.

I agree with Roel on the difficulty of finding a sensible metric for deciding when to serve web fonts. All the more, variable fonts help out with this, because once you make the decision to load a web font, you get the benefit of the entire interpolation range at less impact compared to downloading each and every one separate. And in terms of optimization it is not just the size of the fonts, though. Reducing the file requests in total is a common optimization metric, because both the browser and the server need to handle transferring many files at the same time, and a negative impact can start to surmount the actual download impact - which is why many sites ship all CSS or all Javascript as one file.

The hypothetical point has been made when Variable Fonts were first announced that would this not result in "one master font" for all the fonts there is - obviously that is unfeasible. What I wonder though, could you not package several even vastly different fonts into the same Variable Font by supplementing the glyphs with extraneous points where needed and subdividing the interpolation ranges between the included families? I would not be surprised if somebody tried hacking this already.

Thomas Phinney

Yes, you could do that. But other than to prove a somewhat insane point, why would you? Eliminating the interpolation between the designs would be getting rid of the primary entertaining aspect of the exercise.

You also need the fonts to share the same character set and OpenType features and so forth. Yet... you aren't likely going to save that much space over an OTC/TTC collection if the designs are so different.

Johannes Neumeier

What I meant was that couldn't you duplex the interpolations, so any axis would be split between the number of non-interpolable original fonts, e.g. font A interpolating between 0-49 and font B between 50-100. As you rightly point out the optimization gain hinges on the amount of necessary extraneous nodes, but then again the whole argument for web fonts optimizing performance would be invalid if not also equally valid for this case.

Not sharing the same charset or OT features is probably a good pragmatic reason never to even try this. There also is a point to be made against added complexity, of course, but optimization has a track record of weird and unintuitive solutions.

Cory Maylett

Johannes Neumeier said:

I agree with Roel on the difficulty of finding a sensible metric for deciding when to serve web fonts.

There's currently no infallible method to optimize downloadable content — including web fonts — for the device or for latency. But infallibility does not make meaningless the efforts that, on average, provide a better user experience for most of the target group.

For example, a relatively high percentage of those accessing a website at lower resolutions and from smaller browser windows do so from devices and connections that warrant a reduction in the byte size of the data being transferred. This assumption and the remedies that follow aren't infallible, of course, since some people just might have their desktop computer browser windows pulled in to narrow widths or be pulling in data on their mobile phones over high-speed WiFi.

More problematic might be the assumption that higher-end device users have fast connections when they might very well be accessing the internet over something as slow as a mobile phone hotspot from an iffy G3 connection.

Even so, it's still sensible to tailor content to assumed user profiles since doing so, more often than not, improves the user experiences of most — especially when that tailoring is done in ways to mitigate adverse effects on those not fitting the assumed profile.

In almost all design decisions, certain assumptions must be made about target audiences. Those decisions are rarely perfectly aligned since the audience is rarely homogenous and the data regarding them is often imprecise. As a result, ideal solutions are often not possible.

Still, an imperfect solution that considers and weights the variables then uses that information to produce a design optimized for audience dynamics is still a better solution than one that does not.

Cory Maylett

Roel Nieskens said:

I think the difference with responsive layout and webfonts is that a layout is made malleable to fit any sort of screen, and you let each device sort out which layout it needs to draw. As a developer you create the layout and instructions by which a device can decide what to draw, and you send that to each device. They all get the same "package" and there's no real difference in performance.

They're unlikely to get the same package if I designed the site. In the absence of cookies or various server-side actions, a user will typically be served the same HTML file, but the associated files called in by that initial file (web fonts, images, scripts, CSS, embedded video, etc.) can be selectively removed, added to or changed in various ways.

Many aesthetic niceties that serve to create a more attractive and usable experience on larger displays can impede usability on smaller devices. I typically strip out many of these bandwidth-hogging things on the less-than-perfect assumption that the experience will be improved for these users as a result. 

In addition to stripping out all but important web fonts, I'll routinely remove non-essential images or serve smaller equivalents. I'll also typically remove (or add) references to external CSS files and various scripts that have a high chance of being irrelevant based upon the user agent data.

As for a fallback series of local fonts, yeah, that's a given and always has been, even before web fonts became an option.

Regarding your phone pulling in a new set of fonts when you tipped it to landscape mode, I don't know the site, so I don't have opinions on how it was done or whether it should have even been done. What I will says is that many people think the ability to tip a phone on its side to get a more full-featured experience is actually a good thing — at least if the developer handled it the right way.

By the way, I'm not meaning to come across as argumentative or be pedantic either. It's just a good discussion and sharing opinions.

Roel Nieskens

We're describing different approaches to web development, and both have their place. Juggling different versions of CSS and JavaScript, sniffing user agents, assuming metric A will also represent metric B — to me it feels like going against the grain of the web. If version X of your site can do without non-essential stuff, why serve it for version Y? You can still offer a great user experience without having to resort to Frankensteining your functionality and assets.

On the other hand, keeping things simple and cutting loose legacy browsers isn't automatically a good fit for all projects either.

Going back to typography on the web, the question will soon be: do I want all my weights and widths loaded as separate fonts when variable fonts aren't supported? There'll be projects where the answer will be a definitive yes, and there will be projects where you might fall back to just two weights, or maybe even system fonts.

I suppose that's where it gets interesting for type designers: how will web developers bring twelve variants down? Or will they just fetch those twelve separate fonts? Do they want to generate a few very specific variants from the variable font? Use the default "old fashioned" fonts that came with the variable font? What's allowed by the license? Will developers even care? Or will the ubiquitous, out-dated "bulletproof @font-face" continue to reign, making variable fonts a novelty for the small niche of webdevelopers who also care about typography?

Cory Maylett

Roel Nieskens said:

If version X of your site can do without non-essential stuff, why serve it for version Y?

There are lots of different reasons.

For example, an average user on a mobile phone visiting a page with lots of information is typically less likely to spend as much time on the page as someone sitting in front of a desktop display. So you might want to design a simpler, straight-to-the-point layout for mobile and a more involved page with additional content for desktop users.

I spend a good deal of time doing A|B testing for client marketing purposes, and I've repeatedly found that using different content and layout approaches for mobile and larger displays almost always yields higher levels of engagement than when I use a similar approach for both. This is especially apparent on e-commerce sites where results can be measured in sales figures.

Aesthetics and emotional impact play a role in reader engagement. A small handheld device is a very different canvas than a 27-inch desktop monitor. A design that takes the pros and cons of each into consideration can be more effective at communicating with the target audience.

I could go on, but my point is mobile and desktop users are different enough that what might be seen as essential and/or beneficial for one can be a hindrance for the other.