I'm wondering why we don't hear much about more use of variable fonts on the Web?
I don't mean people talking about what benefits variable fonts can offer for the Web. I mean hearing about sites that are choosing to incorporate variable fonts to take advantage of benefits in regard to performance, richer / responsive typography, text effects, etc.
Is it that use of variable fonts on Web sites is growing but that's just not getting talked about?
Or is it that there are things hindering adoption on the Web? And, if that's the case, what are those hindrances?
There's been support for variable fonts across browsers since 2018, and people like Jason Pamental and Mandy Michael have been promoting the benefits. But what might be hindering adoption?
- Not enough Web designers have heard about variable fonts?
- The benefits that have been talked about aren't compelling enough for Web designers/developers?
- Web designers have been hearing about it, but are leery of trying something still relatively new, or just haven't had opportunity to learn?
- Even small differences in CSS coding (e.g., specifying ranges in @font-face rules, like font-weight: 125 750) is too much of a learning curve?
- Limitations / issues in current CSS that hinder usefulness of variable fonts?
- Limitations in frameworks/tools (Wordpress, SASS, ...) that Web developers and Web content authors use?
- Costs of licensing variable fonts, or confusion around licensing of variable fonts?
- Not enough availability of variable fonts as Web fonts?
IMO this is asking about the wrong kind of tooling.
The issue is that most people who work with fonts are designers, not engineers. If you can’t use a variable font in Figma, you can’t hand it off to a UI engineer to implement.
Where I work, there’s nothing preventing a bundler like webpack from loading a VF for our websites. Nothing preventing our Swift (iOS) or Kotlin (Android) setups either. Engineers have been warm to the idea as I’ve presented it; serving one network request for multiple styles is intriguing.
But our designers use Figma, mostly, as well as Principle, After Effects, Illustrator, and so on.
One out of four of those apps supports variable fonts.
It’s not feasible for a design org our size to use a mix of static and variable fonts to accommodate the majority of apps that don’t support variable fonts. Not because it’s not possible, but because it’s not worth the effort of keeping all these fonts and settings in sync. so I recommend that we don’t use them, and I’m the one who wants to use them the most!
I really can’t overstate Figma’s influence in enterprise UI design today. It’s akin to asking why people in 1998 wouldn’t use variable fonts if Photoshop didn’t support them.
60 years after Karl Gerstner wrote “Designing programmes,” there are now entire teams of designers and technologists doing this type of work at large enterprises, whose discipline falls roughly under “design systems.” They would be the first movers on VF, but they can’t. Figma (and interoperability with other tools) hasn’t made it plausible yet.
Like you, I really only see variable fonts in what I might call “boutique” settings, where maybe it is one person doing the design and implementation. And even then they probably have less control than if they were running a Wordpress site. These days it’s Shopify, Squarespace, etc. The designer-implementer on the web feels less common these days, with increased specialization and separation of concerns at tech companies.
Stripe, which I believe is using a variable version of Söhne from Klim, is one of the exceptions I’m aware of.
Further to Jeremy’s point, even if the static font styles specified in the Figma files could be and are deployed via variable fonts, the more interesting dynamic aspects of variable fonts are not utilised because they are not spec’d.
I'm reminded of the story Matthew Carter tells of the creation of his typeface Charter. Memory in early PostScript printers was scarce. He had the idea to create a typeface with as few nodes and handles as possible to address this. When he presented his solution, he was told that it wasn't a problem anymore. They had figured out a way to compress font data. (This is from memory, so forgive me if any details are wrong.)
Given that this idea has been tried twice now (first with MM and GX in the nineties) I worry that it might be a bit like 3D movies, where every few decades it's the next big thing, but then it turns out not to be.
Or maybe we just need to wait for Figma to get onboard.
Btw, the Web Almanac report for 2020 reports that variable font usage on the Web increased from 1.8% of pages in 2019 to over 10% in 2020. That's significant, but it's still limited, and even that much I don't hear talked about much.
Being infinitely variable is fundamentally different than having a discrete number of axis states to choose from.
It may well be for the user that it is the more practical design tool which offers a limited number of discrete options, rather than unlimited choice.
You known what they say about constraints, how they focus design.
Slider controls which indicate “static” named values such as “Medium” are important.
That’s more difficult for axes other than weight.
Another issue: when making a traditional font family of weights, one avoids a particular point on the axis, at which the vertical stem thickness equals the space between stems (most apparent in words such as millennium)—too much dazzle/sparkle—yet such pitfalls lie in wait for variable font users.
So, the type designer’s determination of a set of weights is a useful and sophisticated thing, part of what makes a typeface what it is, its personality—handles by which font perusers may grasp a type’s identity. The more axes are added to a “typeface”, the more diluted its personality becomes, as the particulars of the font in play migrate from type designer to typographer.
Certainly, it’s interesting to have new qualities such as fonts that bleed, but ultimately I imagine layout applications in which a very few comprehensive metafonts are embedded, and a multitude of type styles are provided by plug-ins which curate specific combinations of axis “pre-sets” such as “Bodoni”. A challenge for type designers.
It may seem silly that having to communicate the difference between a font used in a Figma file and one that should be implemented would cause so much trouble but the various points of friction really add up across multiple tools when you’re talking about hundreds or thousands of people trying to stay in sync.
RE keeping design spec and implementation in sync I’m keeping my eye on the nascent Design Token W3 community group. They haven’t addressed typography yet, and I’d like to be in the room when the get to that module: https://www.w3.org/community/design-tokens/
The reason I mention this is that design systems teams are very invested in this idea. Simultaneously, I am not aware of much thinking on font feature variations in this arena so far.
From my POV:
– Designers like the animation potential and (in some cases) the ability to fine-tune axes. Design apps will catch up, including Figma. They said they’d launch VF support at some point, hopefully sooner than later. We design our minisites in Figma and I’d really love to finally be able to use them in the app.
– Developers like the idea of having a single file to deal with for all (or often, half) of their website’s type. Smaller font sizes is a thing, sure, but it’s really mostly the aspect of having to deal with only single file that’s super nice for them.
– The above is especially true for mobile apps where the file size doesn’t matter as much.
– Foundries will always have to deal with the lack of feature support by certain apps. For example, I’d love it for Excel to just support this incredibly novel typographic feature that is tabular numerals. VF will not change that one bit, and will surely increase the complexity. On the other hand, let’s be honest, VF fit pretty nicely in most production processes already.
Overall: give it another year or two. It’s quite possible that some large websites are going to upgrade to variable fonts in that time frame—don’t forget how long production cycles are for larger changes for sites like that. It can easily take 12 or even 18 months to make it to the end user.
1) Adobe Fonts web service (the former Typekit) not supporting them (the former . This is pretty big.
2) Figma not supporting them, as noted, is also important.
I am a bit surprised by the lack of interest in the trend here. If we went from 2% to 10% of web sites using variable fonts between 2019 vs 2020, I think it will be VERY interesting to see the 2021 percentage when those stats are in.
I guess many web users/developers are seeing/using them without even realising. Open Sans was recently upgraded to a VF and it has around 40 billion requests a week.
From 2018-2020, Google Fonts spent a significant amount of time with Type Network and others to upgrade the classic families to variable fonts. Out of the 1,321 families served, 197 are VFs, https://fonts.google.com/?vfonly=true.
Website development agencies account for some sites. But they're generally the mid-and-higher-budget and trafficked sites that call for custom scripting and where various tasks are divided among specialists. The designers at these agencies are the primary users of Figma, but in addition to Figma, there is Adobe XD and Sketch, among others.
Despite this lack of support from the apps they use, adding variable fonts during coding is a simple task. Designers can easily communicate it to the coders and developers, but they seldom do. The lack of variable font support in applications like Figma undoubtedly contributes to the general scarcity of variable font in use, but I suspect it's a small part.
As for WordPress and the other common CMS platforms, most of those sites are built from templates in various frameworks — modified with downloaded add-ons and to whatever degree the templates easily make possible.
Do-it-yourselfers build many of these websites. Others are put together and coded to some degree by the designers using them. Sometimes, a team might be involved using something like Figma, but more often, that's not the case. At least I know it hasn't been on many of the sites I've designed and coded.
These off-the-shelf templates typically have typographical options, but few include variable font support in the admin interface. Again, it's a simple matter to code them directly into the template or an override. However, most users of these CMS platforms — especially WordPress — aren't coders and steer away from even the simple stuff.
The growing number of sites constructed with online drag-and-drop web builders are put together mainly by amateurs who want quick and cheap brochure websites. Most people using them have never heard of variable fonts — they just choose from the options presented.
I'm a graphic designer/art director who's been building websites since about 1993. I regularly talk to other designers who look at typography from a considerably different perspective than type designers.
They're great at using typography to achieve the right look, personality, and emotional quality in their layouts. However, if you ask them about font technology, such as OpenType features and variable fonts, you'll typically get a deer-in-the-headlights response.
Could this account for some of the “invisible” use Marc mentioned? E.g., no tweaking feature variations, just one font file providing both the regular and bold
There's also the backend admin panel where users enter content. The WYSIWYG admins of most content management systems (including WordPress) try to remove the need for user-entered coding as much as possible. Instead, the interfaces rely on buttons for the various <H> elements plus bold and italic. Styling those elements with variable fonts is doable, but the end result will look mostly the same as if static fonts were used.
For example, take the Typedrawers forum, which is run out of a CMS. Would it make a difference to most people whether the bold is called in from a static bold font or defined via CSS as the 700-weight of a variable font axis? They'd look the same.
In addition, there's the issue of backward compatibility with older browsers. I don't have the figures in front of me, but last I checked, around 10 percent of total browsers in use on the web don't support variable fonts. Mitigating that problem alone is enough to dissuade most web developers.
A variable font being a smaller download than an equivalent set of static fonts has merit. However, saving, say, 64KB of download space on an average web page of 3MB isn't necessarily large enough to offset the downsides I've mentioned — at least for most websites.
To summarize, I don't think the scarcity of variable font use in websites is due to one or two main reasons. Instead, it's at least a dozen different smaller reasons that add up.
If you do a Google search for “Which browsers support variable fonts?” you will find it difficult to determine which sites have the current information. That’s the dilemma faced by web designers who have to decide whether it’s worth subjecting their clients to complaints from users with older systems. Most will decide that it’s simply not worth it. A similar suspicion is held by those who wonder about support for some of the more exotic OT features. Type developers like to keep busy and some seem to have become addicted to complexity, but users of type reject the idea of the ground shifting under their feet. We like our type to be safe and dependable. At the moment, there’s just not enough to be gained by using variable fonts, promising though they may be. Many of those currently available (according to v-fonts.com) seem to be more interesting than useful, and many are sadly underdeveloped.
For print designers like me, who consider themselves to be serious typographers and who work with extended texts, variable fonts have the promise to bring back aspects of Multiple Master fonts that I found advantageous: a way to adjust optical sizes, weights, and widths to produce more harmonious designs. But there are now static font families that have size-specific variants that, if imperfect, are quite good enough. It’s been a real pleasure to see fonts that I admired and used in metal but avoided ever after, such as Futura or Walbaum, appear in recent new versions that perform well on the page in many sizes and weights, even if my idea of the “perfect” weight for a particular situation is almost, but not quite, there.
Back in the mid-1990s, I made a very elaborate museum catalog using MM Minion throughout. As it was produced just before the advent of PDF print workflow, the files can no longer be retrieved, and even if they could be, they couldn't be edited. I’m loathe to take that chance again. I think Adobe made a major mistake by abandoning MM as a commercial product, if only because it discouraged people from taking chances. I do, however, understand their frustration when they found that many people who claimed to be interested and excited by MM proved to be too lazy to work with it. (I found it to be much easier than many claimed it to be.)
Shopping for fonts is like venturing into a category 5 hurricane, with debris flying all around as you search for a diamond. Adding the complication of variable fonts might just be more trouble than it’s worth, at least for now. Yet, I wouldn’t discourage anyone from making more of them, because eventually it might succeed.
>They promoted two use cases that don’t resonate with most designers.
I was just reviewing what it was we actually said wrt benefits and use cases at the announcement at ATypI in 2016. A few things we mentioned
But the bigger things we touched on had to do with motivations that came from the emergence of Web fonts and responsive design. So, we called out two things in particular:
- integration with other parts the OT format
- interoperability across platforms and with CSS
- familiarity for type designers that have worked with design tools that use interpolation
- size/bandwidth savings
- the continuous-variation capabilities that could provide new typgraphic opportunities in applications
The latter could involve "novelty fonts", though we didn't call that out as a key use case. Behdad did give a brief demo using the Buffalo Gals font, but it was only to call out that custom axes could be used, and that there would be something proposed in CSS to allow use of custom axes.
What we did call out as examples of possible typographic capabilities in apps were
(See the video of the announcment, starting around 6:45.)
In hindsight, I think we could have called out novelty fonts, but emphasizing things that might be done for motion graphics or virtual reality environments.
I just designed a couple of headstones. Used optical size (for serif fonts) and weight (for sans serif) variations to make different sizes look “right” together. I did this without the benefit of actual variable fonts, so it isn’t perfect, but it will have to do.
When compact audio disc players first became available in the early 1980s, the audiophiles with money to burn (the early players cost around $2000 = ±$5500 in today’s dollars) bought any disc they could get their hands on: train whistles, bird songs, Kenny G—anything. Not many players were sold at first. It wasn’t until the big labels started releasing their vast backlists of LP recordings in the new format did the whole thing take off, thereby driving down the cost of the player units. I’m thinking that a similar situation exists with VF fonts.
If there were VF versions of the fonts I use and depend on, I’d buy them in a flash (my previously stated concerns notwithstanding). But that’s not what’s happening. What have been published so far (according to Nick Sherman’s site) are largely new fonts, with only rare exceptions. The world can barely absorb more new fonts in any format and professional designers, who are the target market for VF, want the fonts they already depend on before they consider new ones. Until the largest founders step up with VF versions of their most used types, I fear that the format will languish.
Other than some specialised or ‘novelty’ projects in which variation is the principal feature of the design, I have seen very few variable-only releases. Variable fonts are still mostly being offered as a packaging option alongside static font families, whether as a separate product or bundled with the static fonts. Since users are familiar with working with static families, there may be little impetus for them to switch to using variable fonts, especially if they are only using a couple of styles.
Certainly there are a bunch of Adobe Originals in this situation, where it is more an issue of data management and tweaking than it is of design problems: Kepler, Trajan, many others (including my Hypatia Sans). Not that the production work would be trivial, but for some of these it is “just” production work.
One obstacle with purchasing (and subsequently using) variable fonts is that doing so essentially means buying the entire type family. Most display fonts, however, are sold as one-offs for a particular purpose. In those situations, the extra expense for the variable fonts isn't justified when all that's needed are one or two weights.
Something that might keep variable fonts from drifting into obscurity, like multiple masters, is that they're essentially by-products of designing a larger type family. Since the most efficient way to create a type family is to interpolate the mid-ranges, saving out the variable font becomes something of a no-brainer. This alone might put time on the side of their ultimate widespread use.
Since variable fonts involve designing only the end-of-the-range masters, the efficiency should eventually bring down variable font prices (that and competition with growing numbers of free-to-use variables). These lower-cost, full-family variables could, in turn, make buying the equivalent higher-priced static font families uneconomical. At that point, foundries would need to release their mainstay older fonts as variables to stay competitive.