Proposed Web Fonts API Not Coming to WordPress 5.9, Possibly Landing in Gutenberg First – WP Tavern

Justin Tadlock
After what seemed like a shoo-in for WordPress 5.9, a proposed web font API was put on hold. The feature would standardize how theme and plugin developers load fonts and lay the groundwork for future user-facing features.
Jono Alderson opened a ticket for the feature in February 2019. In recent months, the proposal picked up speed. The pull request had over 200 in-ticket messages, 93 commits, and code approval from two core committers. The API seemed ready. However, it hit a standstill in the past few days.
Andrew Ozz, a lead WordPress developer, essentially halted the possibility of the new API landing in 5.9. He stated that he did not think the proposal was ready for WordPress.
“Purely as code it looks good,” he wrote in the ticket. “It is really well documented (thanks [Tonya Mark]!). However I still cannot see how this would make WordPress better in the short and long run. We were chatting with [Andrei Draganescu] and he suggested that ideally this should have been a feature plugin, and I agree. Then it would have been possible to really test it in production, verify (or reject) the assumptions that were made while creating it, and make it into a really worthy addition to WordPress. Unfortunately it’s too late for this now for 5.9.”
One of the issues with testing feature plugins for APIs is that they are not often adopted, as others noted in the ticket. Developers would not rely on them in production in most cases. And, the average end-user would not install something specific to developers.
“Suggesting this be done as a feature plugin is an elegant way to delay something for a few years,” said Ari Stathopoulos, one of the developers behind the API. However, he pointed out the REST API being one exception that performed well enough to get ported into WordPress.
The core WordPress proposal will likely be pushed into the Gutenberg plugin for further exploration. This would be a sort of compromise between launching as a separate feature plugin and going into WordPress 5.9.
The web fonts API is not directly related to the block system. Both traditional and block themes, as well as plugins, could make use of the feature today. However, several Gutenberg proposals rely on the existence of the API, such as allowing theme authors to define web fonts via their theme.json files.
Ozz listed several questions around the proposal, and several developers replied to each. However, his primary argument hinged on the practicality of why everything in the API was necessary, stating that prior replies had been “in principle” and seemed to be based on assumptions.
On the most basic level, the web fonts API would allow developers to register and load locally-hosted fonts or those from Google Fonts. Developers could also add custom providers outside of the two defaults. The first iteration of the proposed API was more about setting down a foundation to build upon in future WordPress releases.
The appeal of the feature is not simply loading fonts. Technically, theme authors could do that with a single line of code if they wanted to. Four lines of code if they wanted to follow current core WordPress standards, at least on the front end.
Stathopoulos rattled off a list of improvements such an API would bring to WordPress and its extensions.
This was a small sampling of the arguments in favor of including the API in core WordPress.
“There are many improvements in Gutenberg that are in limbo, waiting for a web fonts API,” wrote Stathopolous in the ticket. “Not having a web fonts API is a blocker at this point. It’s not a good-to-have item in our wishlist, it is a requirement in order to move forward.”
Currently, no standard specifically relates to web fonts in WordPress. Theme authors piggyback off existing functions for enqueueing a third-party stylesheet or a custom one with @font-face rules. That has generally been an accepted practice in the theme author community over the years.
However, many have accepted it grudgingly. Several have created custom scripts to ease pain points. Many others just copy whatever method the latest default WordPress theme happens to be using.
One of the goals is to make it so that developers do not have to worry about doing all of the extra work involved with loading web fonts. There really should be no need for a theme to figure out how to load them in both the editor and the front end, handle preloading, or account for localization. As themes age and third-party APIs like Google Fonts change, there would be no need for themes to update if WordPress takes care of it under the hood.
The problem of how best to load web fonts multiplies when you throw plugins into the mix. Generally, themes do all the heavy lifting when it comes to design. However, some plugins leap into that side of the WordPress world to add extra style options. There is no way to solve conflicts when loading multiple copies of the same font. Nor are there any surefire ways to disable a theme’s fonts and replace them via the plugin.
One such plugin author emailed me to let me know the news I had already known. The web fonts API appeared to no longer be landing in WordPress 5.9. The developer was gearing up to launch a new website and service on top of the new feature. They even had a mascot. As of now, it might just have to wait.
The feature freeze deadline was two days ago. Therefore, it is unlikely the web fonts API gets added back to the WordPress 5.9 milestone. Maybe developers will see it when 6.0 lands. Maybe pushing it to the Gutenberg plugin breathes some more life into it, allowing contributors to move forward with new features that rely on it.
Disappointing postponement. woff2 mime type would have become available, afaik.
The api itself is a fantastic idea but putting it in a feature plugin as an intermediate step is nonsensical.
The rest api made sense as a feature plugin as there was a large number of people wanting to to use what was for WordPress a very powerful new feature which everyone knew was going to hit core eventually
But the fonts api will simply be a better way of enqueueing fonts. That is great but won’t provide much incentive to test or standardise the api.
Feature plugins are great in some circumstance but not others
More disappointment for developers!
WP are also blocking other developer value adds like logging.
A mindset change is needed.
Nice idea.
Won’t stop plugins/themes to bypass the enqueue API, similar as with scripts now:
Immensely disappointing, and at least at the surface, it feels like another case of devs putting design features last. And shouldn’t the discussion about whether this is of value to WordPress have happened long before now? A bunch of people worked hard on this, but apparently it only takes one lead developer who for some reason doesn’t understand why it’s valuable to almost cancel the whole thing. If people didn’t specify clearly enough why this is needed, it’s because it feels obvious to everyone.
If I’m missing something about this situation or why rolling out this API could be a bad idea, I’m happy to hear more.
Thanks for the thoughtful coverage.
I fully agree. In a time where performance is everything, I see some serious benefit to this feature, especially when it comes to duplicate requests. Granted that it’ll still take a long time before theme/plugin developers adapt this feature into their application.
Sorry for being late to the party, been having some health issues 🙂
Yes, I hear you! It is a 100 times more frustrating to have to make these recommendations in the last moment (yes, these are/were recommendations although that’s not very clear).
In your opinion what is better:
1. Have a brand-new, pretty complex, virtually untested API that leaves some “unanswered questions” about the way it works. Once added to WordPress it will have to be supported and maintained “forever”.
2. Make the current patch into a feature plugin that follows the standard WordPress development practices. Then have it tested well, any bugs or inconsistencies fixed, and any questions answered before adding it to core.
Frankly I’d always go for 2. There is a reason feature plugins exist. This is the way to build better software.
Im my impression option 1. is done since more than two years with rapidly evolving block editor in core – besides the maintained “forever” part. Core updates nowadays often simply break compatibility in block related functions and shifts the neverending maintenance to third party theme and plugin authors to sort it out.
You are right, this approach is really not how better software is built.
Just FYI for all that would like to continue following the development:
Shameless plug: while we’re all waiting for the Web Fonts API to be incorporated into the core, I maintain a plugin that makes it painless to host web fonts locally while also improving performance. It’s based on Zach Leatherman’s extensive research on the subject.
Search for “WP FOFT Loader” on the repo. That’s not a typo: FOFT not FONT.
Your email address will not be published. Required fields are marked *

document.getElementById( “ak_js_1” ).setAttribute( “value”, ( new Date() ).getTime() );
This site uses Akismet to reduce spam. Learn how your comment data is processed.
Enter your email address to subscribe to this blog and receive notifications of new posts by email.

WordPress Tavern is a website about all things WordPress. We cover news and events, write plugin and theme reviews, and talk about key issues within the WordPress ecosystem…
© All Rights Reserved. Powered by WordPress, hosted by Pressable


Leave a Reply

Your email address will not be published. Required fields are marked *