A web font API could come to WordPress – WP Tavern
Ari Stathopoulos announced a proposal for implement a web font API in the WordPress core. 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 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 Web Font 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 touched a font loading package at the same time, by creating a simple set of functions for queuing and removing stylesheets from fonts. It was an idea built on top of a tutorial written by JosÃ© 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 too noted in the print request that once this fix is ââcompleted, the next step would be to submit a new ticket for web fonts 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 build a font loading API now, 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 said. commented on the original post.
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.