Server-Side Font Face CSS Generation and Printing: Ongoing Roadmap (formerly the Fonts API)

[hellofromtonya]

This is an epic ticket to share the ongoing roadmap including:

• the vision of how this supports typography features (e.g. see Global Styles Ongoing Roadmap #41232 and Global Styles/Typography: Managing fonts #45271).
• tracking of ongoing work and needs in preparation for WordPress 6.4.

Updates:

• 28 July 2022 After discussing with @mtias, added the Font Library and FAQ sections
• 18 Jan 2023 API renamed to Fonts API
• 19 Jun 2023 Scope changed, introduce Font Face, and deprecate Fonts API

Changed to Font Face: to server-side generate and print fonts' @font-face styles

With the introduction of the new Fonts Library, the role of the Fonts API has significantly changed as noted in #41479 (comment).

Previously, its roles were:

• Role 1: Generate and print the @font-face styles for all “enqueued” fonts.
• Role 2: Provide a means for plugins to present fonts to users, who can then decide whether to use these fonts (i.e. through the Site Editor).

Its new role is:

• Generate and print the @font-face styles for all theme defined and user activated fonts.

Fonts will be presented to users via the Fonts Library, rather than through the Fonts API.

Plugins will no longer interact with the Fonts API. Instead, they will integrate directly into the Font Library (once that capability exists).

Font Face "gets" the fonts to print from Theme JSON merged data layer. Fonts are no longer registered or enqueued directly with it.

A full API is no longer needed. Thus, Font Face replaces the Fonts API.

Vision

As part of fonts management and Fonts Library,

This API's job is to provide the backend capabilities to support the "font library" to include font management and dynamic building of the @font-face styles.

The "font library" feature will continue to be built, refined, stabilized, and tuned over multiple WordPress releases.

Font Library

See #50927.

The idea is to have the concept of a font library on a site to

• manage and catalogue fonts
• and then provide users an interface for them to select which fonts to use in the live site.

The fonts in the library can come from:

• a theme bundling them
• a user uploading fonts they purchased
• a plugin

The fonts to be used in the site are saved and available via Theme JSON merged data layer, i.e. WP_Theme_JSON_Resolver_Gutenberg::get_merged_data()->get_settings().

FAQ

What about classic sites?

Yes, supported ✅

Classic themes and plugins can have their @font-face styles generated and printed. How?

Classic themes have 2 options:

• Option 1: Add a callback function hooked in 'wp_head' and 'admin_print_styles' and within that callback function, invoke a new print method and pass their fonts to it.
• Option 2: Add a theme.json file that only defines the fonts. See issue [Fonts API] Proposal: classic themes define fonts in a theme.json file #51714 for more information.

Plugins supporting classic sites can use Option 1.

Ongoing work

Architecture

⭐ Required for Core introduction:

• Font Face: redesign the Fonts API to become only a font-face styles generator and printer #51769 ✅ Done 10 Jul 2023
• [Fonts API] Deprecate and remove all functionality (in favor of Font Face) #51819 ✅ Done 18 Jul 2023
• [Fonts API] Deprecate and remove all functionality (in favor of Font Face) #51819 🚫 until Fonts Library is merged

Performance

⭐ Required for Core introduction:
None

Feature needs

⭐ Required for Core introduction:
None

Future enhancements

• Add font management UI to Customizer for classic themes

Bugs

None

Documentation

• Webfonts API: Document fontFace and it’s values in theme.json schema #41844 ⚪

Backports

Future.

Tracking key

✅ Done
⚪ WIP: work in progress
🟡 Experiment WIP
🍏 in testing or code review
🔴 Danger > immediate action needed
🚫 Blocked

⭐ Needed for WP Core introduction

[hellofromtonya]

The vision for the font management through a formal Webfonts API is now available in the description of this roadmap (ie in the Vision section).

The first priority is to solidify the architecture as all other tasks will be affected by these architectural changes:

• Webfonts API Architecture: Explore leveraging WP_Dependencies existing enqueuing, registration, and internal handling #41481
• Webfonts API Architecture: Remove external access to internal-only functionality #41484

Once these 2 tasks are done, then the remaining tasks can be prioritized along with impacts to update each of them to fit within the architectural changes. I removed the priority labels from each of these other tasks.

[azaozz]

This sounds great! A clear and well defined vision makes the tasks ahead much easier to understand.

Trying to get into a bit more details, perhaps "brainstorm" a little more. One of the hard performance related questions would be: What happens when somebody decides to register the whole collection from https://fontsource.org/ (more than 1600 fonts)? It's pretty pointless (will need a dedicated UI and still the users will have a pretty hard time selecting fonts from such a huge list) but that doesn't mean it's not going to happen.

That led to couple of questions:

1. What is the purpose of registering the webfonts outside of the Global Styles UI. Would registering be needed even there, or a "list of the names of available fonts" (perhaps with preview images for the UI) would be sufficient.
2. How is that UI going to work with possibly hundreds of fonts?

For the first question, in most cases it seems registering can be done together with the enqueueing only for the fonts that are in use. That will speed things up and perhaps reduce complexity a little. Thinking a bit further implementation-wise: should registering a font be needed for enqueueing it? Seems not. A "prior art" is how scripts can be enqueued without a need to be registered.

The second question is harder. Are we talking about building UI similar to the Google's webfonts picker? Seems anything less may not be enough, perhaps. Not sure what a UI for picking one out of a hundred fonts may be, but thinking it would be best to have an idea about it before deciding on the back-end code, so the requirements of that (and future) UI are met.

[adamsilverstein]

Great to see this overview issue @hellofromtonya - this is super helpful as I've been struggling to keep up with the Fonts API proposals & progress.

I noticed several features I see in other font APIs that aren't mentioned here and wanted to know if these are on your roadmap at all or would be something to propose for a future iteration:

• Adding DNS prefetch/preconnect/preload tags to font enqueues
• Supporting for downloading fonts (to avoid external requests), ideally built in/automatic
• Font display attribute (to control what happens during loading)
• subset support (to load part of a font)
• encode fonts to base64/directly inject into global styles (avoids an extra server request)

[desrosj]

One thing that's been bugging me is that I feel like "Webfonts" is wrong when I read it. I did some searching around, and my findings seem to point towards "Web fonts" as the preferred way to refer to this. I know this is a nit, but I think it's important to get it right and be consistent. here are some authoritative pages I found pointing to Web Fonts:

• Caniuse
• Google Fonts FAQ page
• Adobe calls Typekit "Typekit Web Fonts" (see the footer link)
• W3Schools
• The name of the original working group for web fonts
• MDN documentation

Other pages for Webfonts

• This page on W3c about web fonts is wildly inconsistent showing Web Fonts, WebFont, and Webfont.
• Wikipedia is also inconsistent.

[azaozz]

Supporting for downloading fonts (to avoid external requests), ideally built in/automatic

@adamsilverstein Yeah, support for preloading is needed, but not sure what "downloading" has to do here? Thought is was decided that this API is for local fonts only. This has numerous advantages as discussed before. Downloading what, and from where? :)

I'd also think that if a plugin wants to use external fonts from a CDN, like Google fonts, it would still consider downloading the open source fonts as available at places like https://github.com/fontsource/fontsource and not trying to capture the CDN's output (which may also have some compatibility or licensing issues as it is closed source).

[hellofromtonya]

@mtias and I discussed this roadmap for both block and classic themes. From that discussion, I've updated the description of this ongoing roadmap including the "font library" vision, technical details, and a new FAQ section.

The changes include publicly exposing enqueue and remove functionality.

[hellofromtonya]

Thought is was decided that this API is for local fonts only. ~ @azaozz

Bundled in the API is a local fonts provider. It does not include remote font foundry handling. It does provide the means for plugin authors to create custom providers, such as to handle (a) an alternative local fonts approach or (b) remotely hosted fonts.

IMO I don't think Core should force only local fonts.

cc @adamsilverstein @azaozz

[adamsilverstein]

Thanks for clarifying @hellofromtonya and @azaozz

was decided that this API is for local fonts only

It does provide the means for plugin authors to create custom providers, such as to handle (a) an alternative local fonts approach or (b) remotely hosted fonts.

🎉 Great!