Part of #41479.

Introduction

The Fonts API needs to evolve to support is single role in typography management:

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

As shared on 19 June 2023 in the Ongoing Roadmap #41479 (comment), the role of the Fonts API has changed to support the font management and Fonts Library. What was an "API" for managing fonts, now becomes a Font Face generator and printer for @font-face styles.

Changes

With new font management system, the Fonts API (or whatever its new name becomes) becomes "read-only" of the Theme JSON fonts definitions and then prints the @font-face styles for only those fonts.

Change: Register, deregister, and enqueue functionality are no longer needed.

Registering and enqueuing no longer applies. Instead, theme.json fonts are passed in for processing.

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

Change: Add missing fonts into Theme JSON is no longer needed.

The Fonts API / Font Face will become read-only. It will no longer injects fonts into theme.json.

Changes:

• WP_Fonts_Resolver::add_missing_fonts_to_theme_json() is no longer needed and can be removed.
• The code that invokes it in WP_Theme_JSON_Resolver_Gutenberg::get_theme_data() can also be removed.

Change: Automatic enqueueing of user selected fonts from Site Editor is no longer needed.

Before the Font Library, the Fonts API automatically identified and enqueued fonts selected by users in the Site Editor (currently doing in WP_Fonts_Resolver::enqueue_user_fonts()). This is no longer needed.

Change: Support for custom providers is no longer needed.

In this first iteration, only local font files will be supported.

Providers were originally conceptualized to support local fonts (built-in) and Google fonts (custom). With the Fonts Library, Google Fonts will now be built-in and will installed locally in wp-content/fonts/ folder.

What about other remote font services?

Is there enough of a use-case to add custom provider functionality to support other remote font services? If yes, then the Fonts Library will need to add support for custom remote font services. Then the Fonts API / Font Face can also add support for custom providers.

Rename to Font Face

This new design is no longer a true "API". Rather, it's a font face generator and printer. With this redesign, it's time to rename it.

This proposal suggests Font Face, to represent that it's job is @font-face.