A web font API coming to WordPress – WP Tavern
Ari Stathopoulos announced a proposal to implement a web fonts API in the core of WordPress. The goal is to standardize how theme authors store and queue font styles. It can also be used as the basis for other features on the road.
Jono Alderson opened the original ticket for such an API in February 2019. The discussion has continued on and off since then, but has only recently gained momentum.
The proposal would allow developers to save fonts from local files or a stylesheet URL like those provided by Google Fonts and other third-party APIs. This would mirror the functions used to load scripts and styles with WordPress, so developers would have to transition without much of a learning curve. However, some settings are different and take into account the wider range of features needed to support web fonts.
Loading web fonts is nothing new to theme authors. There are several methods to use, depending on whether the files are local or served by a third-party API. However, WordPress never offered a solution, the closest thing to a standard being the copy and paste of what the Twenty * themes were doing. However, various projects have sprung up over the years to handle a feature that many theme authors implement almost as a second thought.
Last year, Stathopoulos and other members of the WordPress themes team launched the Webfonts Loader project, an integrated library for developers. It allowed theme authors to load stylesheets from the Google Fonts API and then store them locally on the user’s server.
I even tried a font loader package at one point, creating a simple set of functions for queuing and removing font style sheets. This was an idea built on a tutorial written by Jose Castaneda in 2016. However, I’m currently borrowing the method used in Automattic’s Blockbase theme, using a mix of
Loading fonts is a relatively straightforward affair, so one might wonder why it is necessary to have a basic API to do this. This is because the 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 going on. It also allows us to build new features on a solid foundation going forward.
One thing not to be overlooked in the ad is the mention of
With recent advances in Gutenberg, global styles, and an effort to consolidate options and user interfaces in the site editor, a Webfonts API is becoming a necessity as it will allow theme developers to define fonts in their theme files. json.
Stathopoulos also noted in the pull request that once this fix is complete, the next step would be to submit a new ticket for web font registration during scan.
The theme JSON file is the underlying code for the overall style system that more and more users will interact with in the months and years to come. If we are now building a font loading API, that leaves room for us to explore. It may even open up future integrations in the backend UI.
I’m not sure what that might look like yet, but it will pave the way for a seasoned theme author to experiment with new user experiences around fonts.
There doesn’t seem to be a way to register commercial fonts from APIs like Adobe Fonts. However, Stathopoulos noted last year that it could be a possibility. “Adding an extra argument in one of the calls to allow fine-tuning of the request headers (and therefore allow API authentication) is something we can definitely do,” he commented on the ticket. ‘origin.
I like the proposal. There might be a few issues that need to be addressed, but the more we standardize these common features, the better. This creates less work for theme authors, allowing them to focus more on defining their designs.