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.
- Themes could define fonts via their theme.json files.
- Font previews in the font-family selector in the editor.
- Showing valid font-weights and styles for a font-family.
- Improved front-end performance.
- Server-side localization for better performance and privacy.
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.
Like this:
Like Loading…
