What problem does this address?

Part of WordPress 6.0 is style variations to empower themers to define webfonts in their theme.json. Twenty Twenty-Two (TT2) introduces different styling options within its theme.json. Within this scope, theme.json defines its webfonts and needs mechanisms to (a) expose the fonts to the typography pickers for user customizations and (b) generate the @font-face declarations.

However, the current Webfonts API is still in development and not ready for inclusion in WordPress 6.0. It needs more discussion, development, testing, and feedback to mature before it's ready. There are concerns of rushing the API into Core before its ready as it will lock the API causing future needs limitations, backwards-compatibility issues, high maintenance burden, performance concerns (enqueuing only what is needed, handling of duplicate font variants, etc.), and plugin limitations for further customization (such as changing the font's source).

Style variations don't necessarily need a mature public API at this point. Rather, it needs the mechanisms to (a) wire fonts defined in theme.json to the pickers and (b) generate the font-face styles.

What is your proposed solution?

Provide a stopgap solution for 6.0 where:

• only the theme's theme.json file defines webfonts.
• move the webfonts handling mechanisms to be internal, private functionality within a theme.json handler.
• prevent interaction with webfonts handling mechanisms in such a way that this code is not accessible outside of its container (such as closure or class).
• continue working on Webfonts API within Gutenberg until it matures and is ready for Core in a future release.

Notes

Keeping the internals really private through abstraction or within a private container

From @peterwilsoncc:

I’d be pretty happy with an entirely private API for themes.json — not @private but actually private in a closure, a private final class, trust us this will be hard deprecated kind of way:

function(){
  $fn = function(){};
}

Basically go to some lengths to ensure that contributors don’t actually end up having to maintain two apis: the temporary one and the permanent one. Extenders often ignore @private (case in point, the million odd sites using a cron private function).

Empowering ongoing API development in Gutenberg

A mechanism (such as a constant or filter) will be needed to disable this stopgap / temporary implementation once it lands in Core. Then Gutenberg can turn off Core's internal webfonts handling to use the Webfonts API.

Props

Props to @desrosj and @peterwilsoncc for proposing a pared down stopgap approach.

Tasks

• Identify the essential pieces from the API to support this stopgap.
• Provide the means to switch between the stopgap version and the API.
• Move all webfonts handling into a private / unaccessible container.
• Remove all code not related to the theme.json file.

Status

• Add an internal-only theme.json webfonts handler that prevents BC breaks when the API is backported to Core (future). PR Webfonts: Add internal-only theme.json webfonts handler - WP 6.0 stopgap  #40493 (but do not merge this into Gutenberg - backport directly to WP Core) 🟢 Done ✅
• Backport the internal-only theme.json webfonts handler to Core Backport: theme.json webfonts handler - WP 6.0 stopgap wordpress-develop#2622 🟢 Done ✅ with commit https://core.trac.wordpress.org/changeset/53282
• Allow Gutenberg's Webfonts API to disable the stopgate internal-only handler Turn off WP 6.0 stopgap handler to use Webfonts API. #40555 🟢 Done ✅