Reduced Web Fonts API May Land in WordPress 6.0 or Not at All – WP Tavern

0

Anyone who has watched or participated in the development of the Web Fonts API can attest that it has been an emotional rollercoaster. At one point it seemed like a shoo-in for WordPress 5.9. Then it was returned to the next version. Sure he was landing again, we find ourselves staring at the runway, wondering where the next dip or turn will take us.

Over the weekend, I had a feeling of dread. Last week’s WordPress 6.0 Beta 1 release seemed premature. I’m just as excited about the next major update as I have been about any of them before. There are tons of great features. It’s OK for some of them not to be polished for a beta, but the problem was the incomplete and missing parts list.

The decision to postpone the Post Author Name block left me perplexed. It’s an obvious pairing for the new Post Author Biography block and seems almost necessary for author model support.

The new Comments Query Loop block, which replaces Post Comments, lacked essential functionality. Luckily, most of them now looked squared.

Then there was the Web Fonts API. I hadn’t paid much attention to it 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 have been some issues that could spoil its inclusion in 6.0. 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 high priority open tickets for the API.

Each of the problematic features tied into other highlights of the upcoming 6.0 release, and the Web Fonts API is intrinsically tied to what is, arguably, the the best of the best of the group: global style variations.

First introduced before the release of WordPress 5.9 and its accompanying default theme, Global Style Variations would allow end users to switch between predefined “skins”. Twenty Twenty-Two would showcase the feature in all its wonder:

Potential variations on Twenty Twenty-Two.

However, the feature didn’t make the cut. It was OK because the web fonts API didn’t fit in there 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 good meal in its own right, but the fonts offer a variety of flavors that users deserve to taste. If we expect a future release towards the end of the year, then Twenty Twenty-Two might seem like old news.

After the release of WordPress 6.0 Beta 2, the time has come for this long-awaited feature that standardizes the way fonts are loaded in WordPress. One truth is almost set in stone: the full API will be deferred to a future release. However, there is a silver lining for theme authors that a theme.json– Only version will be available.

Tonya Mork opened a ticket to reduce functionality to disallow saving and spooling fonts programmatically. Alongside Ari Stathopoulos’ work, the related pull request on GitHub would still allow theme authors to set custom fonts via theme.json and personalized /styles/*.json files.

It’s a compromise on a robust API that many expected, but it’s necessary. Still, there is still no guarantee and the fix should be tested by theme authors as soon as possible.

While I wish the Web Fonts API would land in 6.0, I would be remiss if I didn’t point out that April 12, the release date of Beta 1, was the “effective feature freeze.” This is basically the deadline for new release cycle features.

The establishment of these deadlines is not arbitrary. They give users time to test and report bugs. They allow theme and plugin developers to ensure that their extensions work. When new features begin to land in Beta 3 and Release Candidates, it can sometimes be difficult to catch up on an already rapid cycle.

At some point, WordPress has to play 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 wouldn’t hesitate to break the rules for. My only argument is that it’s such an integral part of the overall style variations that I can’t imagine having one and not the other. Derailing this now will lead to many possible theme advancements for months as developers wait for 6.1.

Share.

Comments are closed.