Status of Webfonts API for WordPress 6.0 Inclusion

After a thoughtful and engaging conversation across the community ahead of WordPress 6.0 BetaBeta A pre-release of software that is given out to a large group of users to trial under real conditions. Beta versions have gone through alpha testing in-house and are generally fairly close in look, feel and function to the final product; however, design changes often occur as part of the process. 2, it felt important to pause and share an update on the status of the Webfonts APIAPI An API or Application Programming Interface is a software intermediary that allows programs to interact with each other and share data in limited, clearly defined ways., how you can help, and what the overall vision for the feature is. If you have any questions or concerns, please share them in the comments. 

Any further updates on the API will be communicated on this Make CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. and in the upcoming release posts as needed.

High Level Status

Work is underway to allow theme authors to use webfonts in theme.jsonJSON JSON, or JavaScript Object Notation, is a minimal, readable format for structuring data. It is used primarily to transmit data between a server and web application, as an alternative to XML. in WordPress 6.0. The goal is to include this work in Beta 3 for testing. This will allow theme authors to utilize web fonts alongside the new Style Variations feature. You can follow the efforts underway in this pull request on GitHub.

However, a public API for plugins to register and enqueue webfonts (similar to scripts and styles) will not be available until a later version for WordPress. This public facing part of the API needs more refinement in order to ensure the best developer experience and long term support. 

Vision

Knowing the “why” behind a feature helps ground the wider conversation around how to proceed, especially since this is an API meant for usage by the community of people extending WordPress. Ultimately, this API aims to achieve the following in the long run:

• Help developers move toward modern theming techniques, with theme.json integration and a move towards a better webfont management system.
• Improve the UXUX User experience of accessing various webfonts.
• Allow for a modern and performant approach to Style Variations, rather than relying on previous theme methods.
• Ease implementation efforts for extenders who need to manage various font options. 
• Lay the groundwork for future evolutions of the API.

By including a first version of this API limited to theme.json in 6.0, this would open the door for a wider range of styles per theme. This would unlock a much smoother and powerful experience for users looking to customize their sites further with blockBlock Block is the abstract term used to describe units of markup that, composed together, form the content or layout of a webpage using the WordPress editor. The idea combines concepts of what in the past may have achieved with shortcodes, custom HTML, and embed discovery into a single consistent API and user experience. themes. Below is a video example of what would be possible with the Twenty Twenty-Two default theme where different style options include different fonts, making for very different looks all within a single theme:

If the webfont declaration in theme.json ultimately doesn’t make it in, Twenty Twenty-Two can rely on previous methods to achieve the same effect but there are concerns around the precedent doing so would set. Specifically, as the default block theme and an early adopter of Style Variations, Twenty Twenty-Two serves as the base theme that aims to provide inspiration for other community themes. Using older, soon-to-be-discouraged methods to achieve this sets a concerning precedent for future themes, making this feature very high impact to release. 

How was this decision made? 

There were a few big concerns with the implementation of the API that was originally being considered for 6.0 including: 

• A sense that the API was not robust enough for extenders and not tested enough to be aware of all potential risks.
• Too many remaining PRs to resolve in time for the release.
• Performance concerns with enqueuing fonts listed in theme.json.

At the same time, removing this functionality would greatly impact Style Variations and theme advancements, both of which impacts themers and users alike. 

This led to the decision to pursue a pared down version that only supports declaring fonts within a theme.json file, that is only available to theme authors, rather than to the wider extender base (i.e., pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party authors). To ensure this approach, the core of the API was put into a private theme.json handler preventing plugins from registering or enqueuing, bypassing the current performance and robustness concerns. This allows for the Webfonts API to work with Style Variations, unlocking unique combinations for users to benefit from and theme authors to explore, while giving it more time to evolve in the GutenbergGutenberg The Gutenberg project is the new Editor Interface for WordPress. The editor improves the process and experience of creating new content, making writing rich content much simpler. It uses ‘blocks’ to add richness rather than shortcodes, custom HTML etc. https://wordpress.org/gutenberg/ plugin.

History

An original Webfonts API was planned for 5.9 but was paused after some concerns were raised around providing support for other providers. From that initial effort, an alternative API to the original approach merged in February 2022, and narrowed the focus to support local fonts. As the PR stated, the difference between the original approach and this more recent one is that it “removes the registry, controller, validator & provider implementations, simplifying the code structure, addressing all feedback from the initial PR, and making it easier to merge in WordPress.”

While this simpler version moved the work forward, registering and enqueuing were still coupled, resulting in registered fonts always enqueued, even if not in use. How best to address these performance issues has resulted once again in a larger scope and more concerns about the best way forward. The foundation of the prior work led to the pathway that is now being pursued. 

How you can help

If you’re keen to see this feature in WordPress 6.0, the main way you can help is to test the current approach and give feedback. To help the API in the long run, get involved in testing it in the Gutenberg plugin where the Webfonts API work will continue to evolve without the stopgap described in this post.

---

Thank you to @priethor @cbringmann @hellofromtonya @ndiego @desrosj @courane01 @peterwilsoncc @webcommsat @bph @costdev for collaborating on this post.