Cancel

Justin Tadlock

A Pared Back Web Fonts API May Land in WordPress 6.0 or Not at All

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:

Potential variations on Twenty Twenty-Two.

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.

Category: , ,
22

22 responses to “A Pared Back Web Fonts API May Land in WordPress 6.0 or Not at All”

  2. Honestly, as an end-user trying to keep up—please, slow it down! We really don’t need all these releases, especially if we need a more experienced person to update WP for us—I generally feel competent to do plug-in updates, especially if they are a X.X.x+1 version, but for things that need back-ups first, I usually have to call in a colleague or developer, depending on the organization (1 has managed WP that takes care of updating WP for me).
    I want to keep everything updated for security, but with features changing so often, since I simply maintain 2 sites, am moving a 3rd from DotNetNuke to WP, and lead the volunteer team working with a developer on a 4th—and NONE of this as a full-time job, but as part of grassroots activism in groups where somehow I am the most knowledgeable—it can be a strain to keep up.

    Create forum topic from comment

    • I find that a lot of the things breaking are partly because plugin developers stop working on the plugins or decide not to support the shift towards blocks and away from widgets. I’m starting to try to build everything with default features and minimal plugins recently, and only work with minimal plugins for new sites.

      My suggestion is to look at what features are fluff and pare down to the minimum. Use what works out of the box and when you get custom plugins, make sure the team behind it is dedicated enough to keep working on it.

      Create forum topic from comment

      • knock on wood, so far plug-ins have been O.K. for me, but my sites are relatively new. Nothing using full-site editing yet, including the site I am moving from DNN, as we want a forum (one of the main reasons for the move, as well as our developer’s retirement), and I have not found a FSE theme that accommodates bbpress, which seems to be the appropriate choice for discussion.

        Create forum topic from comment

        • I’m not saying that we have been working on something with bbPress here at the Tavern, but I will note that it’s going to be tough to find FSE theme support for bbPress. As far as I know, it still requires classic PHP templates, and I haven’t really seen any discussion/movement on what its future holds.

          Create forum topic from comment

          • Do you have a better forum suggestion? I am just starting the conversion, not live yet, the forum will be a new feature so there is no old content to move over. BuddyPress seems more like social media, not topic-based discussions. We have 4 task forces that would each have a forum.
            Our rationale for this is that the board is having great e-mail discussions that we would like to share more widely, to have people in our mailing list, other interested folks, UU or otherwise, participate. Suggestions more than welcome!

            Create forum topic from comment

            • Honestly, I don’t know. I haven’t really dived into the forums space in a while, and bbPress has long been my go-to software (even before it was a plugin). I’ll look around to see what folks are using these days, but I don’t really expect much as far as FSE is concerned.

              Create forum topic from comment

              • Thanks, I am using the Chaplin theme, which does use the block editor, but not FSE, and that should be fine for the foreseeable future. The one thing that bothers me is that it is a very asymmetrical design, with narrow text on the left side of a computer screen, so I may look for another hybrid theme. The bbpress fora look very different than the rest of the site, not sure how much I can customize them, but I think that function is more important in that area.

                Create forum topic from comment

            • I’ve used many forum software over the years and I’ve pretty much settled with Invision for sites that want a more traditional forum style, and Discourse for everything else. I experienced compatibility issues after upgrade decided to keep my site/content separate from my community, hence no bbpress or the likes that rides on WordPress. Discourse is the best solution out there right now IMHO but it is resource heavy and users who are familiar with the traditional forum approaching might find the modern take jarring.

              It goes down to the number of users you have, how active they are, and the types of features they use more often. I’ve come to realise that users don’t need or use all the bells and whistles. They are there for the engagement and everything else is a plus.

              FSE themes seem to be mostly single-column themes. I’ve been looking for some with sidebars, but sidebars seem to run counter to the current theme design trend. I don’t see how bbpress would be able to fit in this approach.

              Create forum topic from comment

              • Thanks for the info; I will check them out.
                I have another site that has a forum that was hosted on a Joomla site; trying to figure out how best to connect that to the new WP site (I moved the Joomla site to WP because I know WP better and did not have the time/inclination to learn another system). That phpbb forum has been in place for most of a decade, has thousands of posts but few current users.

                Create forum topic from comment

  3. I have been waiting for fonts API for so long now. There needs to be a balance between feature release and waiting times. Obviously the WP team seems to be going through a phase where they are not being appreciated much for the updates and releases. Look at the Gutenberg reviews, constant bashing is not good for any team. This is where leadership comes into play, the Gutenebrg product which WP is trying to sell is not yet finished ! Few of my clients who love Gutenberg switch forth and back to Elementor as the slow progress leaves them wanting for more. Till now, Elementor holds the prized position which Gutenberg should have achieved by now. ATM, if Elementor decides to create their own CMS, it will definitely overtake the WordPress as a CMS itself.

    Create forum topic from comment

    • Maybe for some, but one of my sites uses Elementor, and I find it very difficult. All new pages that I create on that site are through the standard block editor/Gutenberg. There is an online comparison of 2 young women with no knowledge of either program recreating the same page, and it is clear that Gutenberg is the easier to figure out. Maybe advanced folks can use Elementor, but for we part-time site maintainers, it is anything but elementary.

      Create forum topic from comment

    • I suppose I’ve never really looked at WordPress/Gutenberg as a competitor to one of the platform’s third-party plugins. Extensions are always supposed to make WordPress “better” in some way for a certain sub-set of users.

      For example, I ran a popular role management plugin for a decade. Many users thought it should have been a part of core. It was certainly more robust than the default offering, but I never thought it needed to be something that WordPress itself bundled. It was there for the folks who needed it.

      WordPress’s main concern should be building a strong base for end-users and a foundation that themes/plugins can build on top of. Things like the web fonts API are very much a part of that foundation.

      Create forum topic from comment

      • I guess I see page builders as competitors, not plug-ins. I am, as mentioned, an amateur end-user trying to keep up, and a slower pace of improvements would enable me to learn and integrate better. I would rather see an end (or limit) to the .x versions and more features in less frequent X.0 versions. X.x versions could be helpful for security features, or things that don’t really affect the user experience, but with some educational materials before a new .0 and time to learn that, I’d be ready for the next features in the next .0.

        I realize that developers have different needs, and they need to know what is coming in a .0 version so that they can be ready with themes, plug-ins, etc., and to work on clients’ sites quickly and efficiently. I trust the WP development team to balance these conflicting needs; prerelease of a version for developers before the public push to get all on board seems like a reasonable option.

        Create forum topic from comment

  4. Overabundance of updates often causes a headache among QAs. Personally, I prefer slower, but more polished progress. A less crowded roadmap, but fewer bugs. I also wouldn’t want anyone to work overnight just so I can get some nicer fonts or other gimmicks.

    Create forum topic from comment

  5. It was notably missing from the first beta, and there was no final decision on its status as Beta 2 rolled out yesterday.

    I wanted to quickly touch on the status of the API and what folks can expect in terms of updates since I’m sure that’s top of mind. A post for Make Core outlining the current status/next steps, light history, and how folks can help is in progress. I intended to publish it sooner but some amazing work by various contributors has led to the post being more about “here’s where we’re headed” (the outcome) rather than “here are all the blockers and general timeline”. It felt important to hold off sharing once this momentum and possible solution came to light. You’ve done a great job of sharing the current state and latest PRs though – thank you for doing so and for following along so closely. It helps bring the community along :).

    In case it’s helpful, I’ll follow up in another comment as soon as I can to shed light on how it might impact style variations and the post author name block situation (as we went back and forth over in slack yesterday). Thank you, again.

    Create forum topic from comment

  6. The web fonts api should be part of core asap, it is crazy that there is no standard way of enqueueing fonts in the same manner as scripts and styles.

    The current situation is a mess and means things that should be easy are hard. More often than not I want to remove all fonts from a theme and fall back to system fonts. Yet atm that requires a full child theme to do this. This is an antiquated situation.

    Instead of adding new blocks and features that are not needed and in many cars should not be part of core (eg font size control in the editor) we should be including this missing standard

    Create forum topic from comment

You may also like

Newsletter

Subscribe Via Email

Enter your email address to subscribe to this blog and receive notifications of new posts by email.