Ari Stathopoulos announced a proposal for implementing a web fonts API in core WordPress. The goal is to standardize how theme authors register and enqueue font styles. It may also serve as the foundation of other features down the road.
Jono Alderson opened the original ticket for such an API in February 2019. The discussion has continued off and on since then but has only recently gained momentum.
The proposal would allow developers to register fonts from local files or a stylesheet URL like those provided by Google Fonts and other third-party APIs. It would mirror the functions used for loading scripts and styles with WordPress, so developers should transition without much of a learning curve. However, some parameters are different and account for the broader feature range necessary to support web fonts.
Loading web fonts is nothing new for theme authors. There are multiple methods to use, depending on whether the files are local or served by a third-party API. However, WordPress has never offered a solution, the closest thing to a standard being copying and pasting what the Twenty* themes were doing. However, various projects have popped up over the years for handling a feature that many theme authors implement almost as a second thought.
Last year, Stathopoulos and others from the WordPress Themes Team launched the Webfonts Loader project, a drop-in library for developers. It allowed theme authors to load stylesheets from the Google Fonts API, then stored them locally on the user’s server.
I even dabbled in a font-loading package at one time, building a simple set of functions to enqueue and dequeue font stylesheets. It was an idea built on top of a tutorial written by Jose Castaneda in 2016. However, I am currently borrowing the method used in Automattic’s Blockbase theme, using a mix of functions.php and theme.json.
Loading fonts is a relatively simple affair, so one might wonder why there is a need for a core API around doing it. It is because standards simplify routine tasks for everyone. When such conventions exist, every developer can look at a few lines of code and immediately understand what is happening. It also allows us to build new features on top of a solid foundation in the future.
One thing to not overlook from the announcement is the mention of theme.json:
With the recent advancements in Gutenberg, global-styles, and an effort to consolidate options and UIs in the site-editor, a Webfonts API is becoming a necessity as it will allow theme developers to define fonts in their theme.json files.
Stathopoulos also noted in the pull request that once this patch makes it through, the next step would be submitting a new ticket for registering web fonts when parsing theme.json.
The theme JSON file is the underlying code for the global styles system that more and more users will be interacting with in the months and years to come. If we build a font-loading API now, it gives us room to explore. It may even open up future integrations within the user interface in the backend.
I am not sure what that might look like yet, but it will pave the way for a savvy theme author to experiment with new user experiences around fonts.
There does not seem to be a way to register commercial fonts from APIs like Adobe Fonts. However, Stathopoulos noted last year that it might be a possibility. “Adding an extra argument in one of the calls to allow tweaking the request headers (and therefore allow API authentication) is something we can definitely do,” he commented on the original ticket.
I like the proposal. There might be a few kinks to work out, but the more we standardize these common features, the better. It creates less work for theme authors, allowing them to focus more on nailing down their designs.
This is a great idea, and I wish the core team would also focus on some of the other missing and underdeveloped apis eg custom post statuses, custom comment types etc.
Instead they seem to be adding more features to Gutenberg, most of which have no place in a content editor.