Anyone who has been watching or participating in the development of the web fonts API can attest that it has been an emotional rollercoaster. At one point, it seemed to be a shoo-in for WordPress 5.9. Then, it was punted to the next release. Sure that it was landing once again, we find ourselves looking down the track, wondering just where the next dip or twist will take us.

Over the weekend, I had a sense of dread. The WordPress 6.0 Beta 1 release last week felt premature. I am just as excited about the next major update as I have been about any before. There are tons of noteworthy features. It is OK for some of them to not be polished for a beta release, but the problem was the list of incomplete and missing pieces.

The decision to postpone the Post Author Name block left me scratching my head. It is an obvious pairing for the new Post Author Biography block and almost feels necessary for Author Template support.

The new Comments Query Loop block, a replacement for Post Comments, was missing vital features. Fortunately, most of those seemed squared away now.

Then, there was the web fonts API. I had not paid it much attention since its inclusion in Gutenberg 12.8 over a month ago. I was happy to see it merged and have used it ever since. However, there has been some trouble brewing that might spoil its inclusion in the 6.0 release. It was notably missing from the first beta, and there was no final decision on its status as Beta 2 rolled out yesterday. There are still several open, high-priority tickets for the API.

Each of the problematic features was tied to other highlights of the upcoming 6.0 release, and the web fonts API is intrinsically linked to what is, arguably, the crème de la crème of the bunch: global style variations.

First touted before the release of WordPress 5.9 and its accompanying default theme, global style variations would allow end-users to switch between pre-built “skins.” Twenty Twenty-Two would showcase the feature in all its wonder:

However, the feature did not make the cut. That was OK because the web fonts API did not squeeze in either. These variations would allow theme authors to mix and match different colors, block styles, and fonts. Like a PB&J without the J, the global style variations feature is a fine meal in its own right, but fonts offer a variety of flavors that users deserve to taste. If we wait for some future release toward the end of the year, Twenty Twenty-Two might feel like old news by then.

After WordPress 6.0 Beta 2’s release, it has become crunch time for this long-awaited feature that standardizes how fonts are loaded in WordPress. One truth is almost set in stone: the complete API will be deferred to a future release. However, there is a sliver of hope for theme authors that a theme.json-only version will be available.

Tonya Mork has opened a ticket for paring down the feature to disallow programmatically registering and enqueueing fonts. Along with work by Ari Stathopoulos, the associated pull request on GitHub would still allow theme authors to define custom font-faces via theme.json and custom /styles/*.json files.

It is a compromise on a robust API that many have been waiting for, but it is necessary. Yet, there are still no guarantees, and the patch needs testing from theme authors sooner rather than later.

As much as I want the web fonts API to land in 6.0, I would be remiss to not point out that April 12, the release date of Beta 1, was the “effective feature freeze.” Essentially, this is the deadline for new features for the release cycle.

Having these deadlines in place is not arbitrary. They give time for users to test and report bugs. They allow theme and plugin developers to make sure their extensions are working. When new features start landing in Beta 3 and Release Candidates, it can sometimes be a mad scramble to catch up in an already fast-paced cycle.

At a certain point, WordPress must abide by its own rules. Otherwise, it feels like some pet features get a pass where others might not.

The web fonts API is one of those things I would not mind breaking the rules for. My only argument is that it is such an integral piece of global style variations that I cannot imagine having one and not the other. Derailing this now will set a lot of possible theme advancements back for months as developers wait for the 6.1 release.