Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

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

Closed
2 of 5 tasks
hellofromtonya opened this issue Jun 1, 2022 · 35 comments
Closed
2 of 5 tasks

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

hellofromtonya opened this issue Jun 1, 2022 · 35 comments
Labels
[Feature] Font Library [Feature] Typography Font and typography-related issues and PRs [Type] Overview Comprehensive, high level view of an area of focus often with multiple tracking issues [Type] Tracking Issue Tactical breakdown of efforts across the codebase and/or tied to Overview issues.

Comments

@hellofromtonya
Copy link
Contributor

hellofromtonya commented Jun 1, 2022 •
edited
Loading

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

Updates:

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:

Plugins supporting classic sites can use Option 1.

Ongoing work

Architecture

⭐ Required for Core introduction:

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

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
This was referenced Jun 1, 2022
Closed
Closed
@annezazu annezazu added the [Type] Overview Comprehensive, high level view of an area of focus often with multiple tracking issues label Jun 1, 2022
@andrewserong andrewserong mentioned this issue Jun 10, 2022
Merged
@bph bph added the [Type] Tracking Issue Tactical breakdown of efforts across the codebase and/or tied to Overview issues. label Jun 20, 2022
@hellofromtonya
Copy link
Contributor Author

hellofromtonya commented Jun 23, 2022 •
edited
Loading

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:

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
Copy link
Contributor

azaozz commented Jun 24, 2022 •
edited
Loading

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
Copy link
Member

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)

@hellofromtonya hellofromtonya mentioned this issue Jul 13, 2022
Closed
@desrosj
Copy link
Contributor

desrosj commented Jul 14, 2022 •
edited
Loading

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:

Other pages for Webfonts

@azaozz
Copy link
Contributor

azaozz commented Jul 27, 2022 •
edited
Loading

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
Copy link
Contributor Author

@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
Copy link
Contributor Author

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
Copy link
Member

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!

@hellofromtonya hellofromtonya mentioned this issue Aug 1, 2022
Closed
3 tasks
@hellofromtonya
Copy link
Contributor Author

I opened a separate issue for renaming consideration per @desrosj suggestion. Let's move the naming discussion to here #42868

This was referenced Aug 1, 2022
Closed
Closed
@hellofromtonya
Copy link
Contributor Author

Tracking the block level typography consistency effort #43242

This was referenced Sep 9, 2022
Closed
Closed
@annezazu annezazu mentioned this issue Sep 27, 2022
Open
@hellofromtonya hellofromtonya mentioned this issue Dec 8, 2022
Closed
@simison simison mentioned this issue Dec 9, 2022
Open
@hellofromtonya
Copy link
Contributor Author

hellofromtonya commented Dec 19, 2022 •
edited
Loading

⭐ Status Update:

Status: Blocked by architectural work.

DONE: ✅ The major architectural redesign (See #41481) is now merged. The new architecture is a code rewrite which has breaking changes. Some high level details:

  • Changes data structures and publicly exposed functions/methods.
  • Includes a temporary backwards-compatible (BC) layer that throws deprecation notices to alert developers of where they need to modify their code to use the API. This BC layer will not be backported to Core.

NEXT: ⚪ There are 2 more architectural tasks that need to be completed to unblock the remaining bugs, performance, and feature work can continue.

👉 Where can you help?

@hellofromtonya
Copy link
Contributor Author

hellofromtonya commented Jan 18, 2023 •
edited
Loading

⭐ Status Update ⭐
18 Jan 2023

Status:

  • Architecture is now unblocked 🎉
  • Work on remaining issues is underway

Big Picture

👉 It's a NEW API
The API has been completely redesigned with a new architecture and renamed including all publicly available functions, classes, and methods.

👉 BC Layer
A backwards-compatibility (BC) layer (with deprecations) was added to ensure sites using this API in production keep running while giving developers time to upgrade to the new API. This BC Layer will NOT be backported to Core.

Who's impacted?

  • Any external code (outside of Gutenberg) that is directly interfacing with the API.
    While the BC Layer will keep sites running, extenders will need to upgrade their code to use the new API, especially once the API is backported to WP Core.

  • Theme's using theme.json are NOT impacted.
    Why? This file is automatically ingested, processed, and defined fonts registered and enqueued within the API.

  • All open PRs (see below)

⭐ 👉 Next steps

  • Identify must-haves for WP 6.2 as these will be the highest priorities.

These 2 issues are must-haves:

All open PRs are impacted. This means each open issue and any of its PRs must be evaluated one-by-one and if still relevant, rebased and rebuilt to apply changes to the new API.

TODO:

  1. Evaluate each PR to determine:
    • Is it still needed?
    • If yes, how should the changes be introduced into the new API?
    • If yes, what priority level should it be for WP 6.2?
  2. Rebase and rebuild PRs:
    Each PR will need to be rebased on top of trunk to bring the new API into its scope. In most cases (if not all), the PR will need to rebuilt.

@felixarntz
Copy link
Member

@hellofromtonya Please let me know how I can help with this effort in relation to WP 6.2. Is there already a corresponding Trac ticket for it?

This was referenced Jun 20, 2023
Closed
Closed
Closed
Closed
@felixarntz
Copy link
Member

Thanks for the update @hellofromtonya! While reading through your comment, I was a bit skeptical on what the change would mean for classic themes since the original proposal would have indeed been agnostic. But as long as a classic theme can introduce support via theme.json only for fonts without having to also opt in to other block theme features, the new direction sounds great to me.

Let's make sure to keep the classic theme considerations on our radar, we need to make sure that the way the Font Library is eventually implemented satisfies both block and classic themes use-cases.

@hellofromtonya
Copy link
Contributor Author

Thank @felixarntz.

Yesterday, I confirmed that since WordPress 6.0.0 (with the _wp_theme_json_webfonts_handler() stopgap code), a classic theme has had the ability to define their fonts in theme.json file (only the fonts) and results are:

  • those fonts get @font-face styles generated and printed.
  • the theme are still recognized as classic, meaning Customizer is the customizing tool, Site Editor does not load, etc.

Cool!

I created this Proposal yesterday to stay with that convention for classic themes, use a theme.json file instead of also providing global functions to directly add their fonts. I'll cross-post your feedback. Thanks!

we need to make sure that the way the Font Library is eventually implemented satisfies both block and classic themes use-cases.

As far as I know, the Font Library will only work with Site Editor, which is only available to block themes. Classic themes use Customizer. I think the better place to raise awareness of classic themes with the Font Library is in this issue #45271, i.e. where managing fonts and font library are being discussed and worked on.

@hellofromtonya
Copy link
Contributor Author

Sorry for the delay in responding to you @webd-uk.

How can we find out more about this because it will need to be used to add fonts that a plugin previously added via other methods. Specifically ... if a user has already selected to use a font via an existing plugin, will there be a way for the plugin to seamlessly pre-select the font via this new Font Library registration method for the user so that the user doesn't have to select the font again?

If the user has already selected a plugin defined font, then that font should be saved in the database when saving those selections in the Site Editor. Those fonts then should be within the theme.json merged data, i.e. WP_Theme_JSON_Resolver_Gutenberg::get_merged_data()->get_settings() within ['typography']['fontFamilies'].

Then when it's time to "print" @font-face styles, the new Fonts API (or whatever name it becomes) pulls from WP_Theme_JSON_Resolver_Gutenberg::get_merged_data()->get_settings() to extract the fonts to print.

As for what gets "activated" in the Font Library, I think it's also using that same data.

What isn't there yet is the means for a plugin to "register" its defined fonts with the Font Library.

I'd suggest asking the question and contributing in the main issue #45271 or in the Font Library's WIP PR #50927.

@hellofromtonya hellofromtonya mentioned this issue Jun 21, 2023
Closed
@webd-uk
Copy link

webd-uk commented Jun 22, 2023

I'd suggest asking the question and contributing in the main issue #45271 or in the Font Library's WIP PR #50927.

Thank you, @hellofromtonya! I will definitely be doing that but need to read up on everything first. Thanks again, Wordpress has needed this built-in feature for soooooooo long!

@hellofromtonya
Copy link
Contributor Author

hellofromtonya commented Jun 22, 2023 •
edited
Loading

Update 22 Jun 2023

New Learnings

New Learnings since my 19th Jun update:

What currently works with the Fonts Library?

WordPress Core ✅
Fonts API ❌

The stopgap code in WordPress Core since 6.0.0 works with the Fonts Library _wp_theme_json_webfonts_handler() and supports classic themes adding a theme.json file with only fonts defined. ✅

However, the Fonts API in Gutenberg does not work with the Fonts Library and must be changed before the Fonts Library is merged. ❌

Should the Fonts API's architecture change?

Yes! ✅

It needs a near complete redesign.

Issue #51769 is for the redesign, transforming the Fonts API into only a Font Face styles generator and printer.

WIP PR #51770 is what I envision as the redesign.

What about classic sites?

Yes, supported ✅

Classic themes and plugins can have their @font-face styles generated without requiring register or enqueue. How?

Classic themes have 2 options:

  1. 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.
  2. 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.

What about font-face property validation?

Yes, still required ✅

To support classic sites and potentially other needed customizations, the new Font Face design exposes a print( $fonts ) method that accepts an array of fonts. Those are the fonts that will be processed to generate and print the @font-face styles.

As any source could invoke that print( $fonts ) method, the passed in font-face properties still require validation. Why? To (a) protect the code from missing properties or invalid data types and (b) provide extenders guidance of where problems are in the array of fonts.

What about "providers"?

Fonts Library only supports serving @font-face src from local assets. It has Google Fonts built into it, but downloads the font files to wp-content/fonts/ for local access.

To keep parity with the Fonts Library, the Fonts API support of custom providers will be removed. The new design will only support local font files. This change will ensure fonts work the same on all types of sites.

If enough of need is discovered, then a future enhancement could be to add custom provider support.

What about sites currently using the Fonts API?

The API is experimental. However, the API has taken the approach of supporting backward compatibility through the BC Layer to avoid sites breaking.

The new Font Face generation is a big big change. Care is needed to consider how to safeguard sites currently using the Fonts API while guiding developers towards where and what needs to change.

This was referenced Jun 22, 2023
Closed
Closed
@annezazu annezazu mentioned this issue Jun 26, 2023
Closed
@ironprogrammer ironprogrammer mentioned this issue Jun 30, 2023
Merged
@mikachan mikachan mentioned this issue Jul 17, 2023
Closed
16 tasks
@hellofromtonya hellofromtonya changed the title Fonts API: Ongoing Roadmap (formerly the Webfonts API) Server-Side Font Face CSS Generation and Printing: Ongoing Roadmap (formerly the Fonts API) Jul 18, 2023
@hellofromtonya
Copy link
Contributor Author

The description of this roadmap is now updated for "Font Face", i.e. to define its new role in font management and its scope of work.

@hellofromtonya
Copy link
Contributor Author

hellofromtonya commented Aug 21, 2023 •
edited
Loading

Update

Font Face is ready to be introduced into WordPress Core. It is a direct replacement for _wp_theme_json_webfonts_handler() in that it processes block themes with the same @font-face styles while providing the means for classic themes and plugins to also print their font's @font-face styles.

TODO:

@hellofromtonya
Copy link
Contributor Author

Here's the Core Trac ticket for merging Font Face into Core https://core.trac.wordpress.org/ticket/59165.

@hellofromtonya hellofromtonya mentioned this issue Aug 22, 2023
Merged
pento pushed a commit to WordPress/wordpress-develop that referenced this issue Aug 31, 2023
@hellofromtonya
Introduce font-face styles generator and printer.
c29b095 
Introducing Font Face, a server-side `@font-face` styles generator and printer. 

tl;dr:
* Introduces Font Face.
* Deprecates `_wp_theme_json_webfonts_handler()`.

**Introduce Font Face**

From an array of fonts (i.e. each font-family and its font variations to be processed), it:

1. Validates each `font-face` declaration, i.e. the CSS property and value pairing. If validation fails, processing stops with no font-face styles printed.
3. Generates the `@font-face` CSS for each font-family.
4. Prints the CSS within a `<style id="wp-fonts-local">` element.

The entry point into Font Face is through a new global function called `wp_print_font_faces()`, which is automatically called:

* when the `'wp_head'` hook runs (for the front-end).
* when the `'admin_print_styles'` hook runs (for the back-end).
* when `_wp_get_iframed_editor_assets()` runs to inject the `@font-face` styles into the iframed editor.

Once called, it gets the fonts from Theme_JSON merged data layer, which includes theme defined fonts and user activated fonts (once the Font Library #59166 is introduced into Core).

For classic sites, themes and plugins can directly call `wp_print_font_faces()` and pass their fonts array to it for processing.

**Deprecates `_wp_theme_json_webfonts_handler()`.**

As Font Face is a direct replacement, the stopgap code in `_wp_theme_json_webfonts_handler()` (introduced in 6.0.0 via [53282]) is deprecated and unused in Core.

**Props note:**
There's a long multiple year history baked into Font Face, which dates back to the early versions of a web font API (see #46370 and [WordPress/gutenberg#41479 roadmap]. The props list includes those who contributed from those early versions up to this commit.

**References:**
* #46370 original (Web)Fonts API proposal for registering and enqueuing web fonts.
* [WordPress/gutenberg#41479 Gutenberg tracking issue] which includes the evolution from Webfonts API to Fonts API to Font Face.
* [53282] / #55567 Added the stopgap code `_wp_theme_json_webfonts_handler()` in 6.0.
* [https://developer.mozilla.org/en-US/docs/Web/CSS/@font-face @font-face on mdn web docs]
* #59166 Font Library: Font manager for WordPress

Follow-up to [53282].

Props aristath, jonoaldersonwp, hellofromTonya, andraganescu, annezazu, antonvlasenko, arena, askdesign, azaozz, bph, bradley2083, colorful-tones, costdev, davidbaumwald, desrosj, dingo_d, djcowan, domainsupport, dryanpress, elmastudio, flixos90, francina, garrett-eclipse, gigitux, grantmkin, grapplerulrich, gziolo, ironprogrammer, jb510, jeffpaul, jeremyyip, jffng, joostdevalk, jorgefilipecosta, juanmaguitar, mamaduka, matveb, mburridge, mitogh, ndiego, ntsekouras, oandregal, ocean90, oglekler, paaljoachim, pagelab, peterwilsoncc, poena, priethor, scruffian, SergeyBiryukov, shiloey, simison, skorasaurus, soean, westonruter, wildworks, zaguiini.
Fixes #59165.

git-svn-id: https://develop.svn.wordpress.org/trunk@56500 602fd350-edb4-49c9-b593-d223f7449a82
markjaquith pushed a commit to WordPress/WordPress that referenced this issue Aug 31, 2023
@hellofromtonya
Introduce font-face styles generator and printer.
8c4c353 
Introducing Font Face, a server-side `@font-face` styles generator and printer. 

tl;dr:
* Introduces Font Face.
* Deprecates `_wp_theme_json_webfonts_handler()`.

**Introduce Font Face**

From an array of fonts (i.e. each font-family and its font variations to be processed), it:

1. Validates each `font-face` declaration, i.e. the CSS property and value pairing. If validation fails, processing stops with no font-face styles printed.
3. Generates the `@font-face` CSS for each font-family.
4. Prints the CSS within a `<style id="wp-fonts-local">` element.

The entry point into Font Face is through a new global function called `wp_print_font_faces()`, which is automatically called:

* when the `'wp_head'` hook runs (for the front-end).
* when the `'admin_print_styles'` hook runs (for the back-end).
* when `_wp_get_iframed_editor_assets()` runs to inject the `@font-face` styles into the iframed editor.

Once called, it gets the fonts from Theme_JSON merged data layer, which includes theme defined fonts and user activated fonts (once the Font Library #59166 is introduced into Core).

For classic sites, themes and plugins can directly call `wp_print_font_faces()` and pass their fonts array to it for processing.

**Deprecates `_wp_theme_json_webfonts_handler()`.**

As Font Face is a direct replacement, the stopgap code in `_wp_theme_json_webfonts_handler()` (introduced in 6.0.0 via [53282]) is deprecated and unused in Core.

**Props note:**
There's a long multiple year history baked into Font Face, which dates back to the early versions of a web font API (see #46370 and [WordPress/gutenberg#41479 roadmap]. The props list includes those who contributed from those early versions up to this commit.

**References:**
* #46370 original (Web)Fonts API proposal for registering and enqueuing web fonts.
* [WordPress/gutenberg#41479 Gutenberg tracking issue] which includes the evolution from Webfonts API to Fonts API to Font Face.
* [53282] / #55567 Added the stopgap code `_wp_theme_json_webfonts_handler()` in 6.0.
* [https://developer.mozilla.org/en-US/docs/Web/CSS/@font-face @font-face on mdn web docs]
* #59166 Font Library: Font manager for WordPress

Follow-up to [53282].

Props aristath, jonoaldersonwp, hellofromTonya, andraganescu, annezazu, antonvlasenko, arena, askdesign, azaozz, bph, bradley2083, colorful-tones, costdev, davidbaumwald, desrosj, dingo_d, djcowan, domainsupport, dryanpress, elmastudio, flixos90, francina, garrett-eclipse, gigitux, grantmkin, grapplerulrich, gziolo, ironprogrammer, jb510, jeffpaul, jeremyyip, jffng, joostdevalk, jorgefilipecosta, juanmaguitar, mamaduka, matveb, mburridge, mitogh, ndiego, ntsekouras, oandregal, ocean90, oglekler, paaljoachim, pagelab, peterwilsoncc, poena, priethor, scruffian, SergeyBiryukov, shiloey, simison, skorasaurus, soean, westonruter, wildworks, zaguiini.
Fixes #59165.
Built from https://develop.svn.wordpress.org/trunk@56500


git-svn-id: http://core.svn.wordpress.org/trunk@56012 1a063a9b-81f0-0310-95a4-ce76da25c4cd
github-actions bot pushed a commit to platformsh/wordpress-performance that referenced this issue Aug 31, 2023
@hellofromtonya
Introduce font-face styles generator and printer.
b8f1384 
Introducing Font Face, a server-side `@font-face` styles generator and printer. 

tl;dr:
* Introduces Font Face.
* Deprecates `_wp_theme_json_webfonts_handler()`.

**Introduce Font Face**

From an array of fonts (i.e. each font-family and its font variations to be processed), it:

1. Validates each `font-face` declaration, i.e. the CSS property and value pairing. If validation fails, processing stops with no font-face styles printed.
3. Generates the `@font-face` CSS for each font-family.
4. Prints the CSS within a `<style id="wp-fonts-local">` element.

The entry point into Font Face is through a new global function called `wp_print_font_faces()`, which is automatically called:

* when the `'wp_head'` hook runs (for the front-end).
* when the `'admin_print_styles'` hook runs (for the back-end).
* when `_wp_get_iframed_editor_assets()` runs to inject the `@font-face` styles into the iframed editor.

Once called, it gets the fonts from Theme_JSON merged data layer, which includes theme defined fonts and user activated fonts (once the Font Library #59166 is introduced into Core).

For classic sites, themes and plugins can directly call `wp_print_font_faces()` and pass their fonts array to it for processing.

**Deprecates `_wp_theme_json_webfonts_handler()`.**

As Font Face is a direct replacement, the stopgap code in `_wp_theme_json_webfonts_handler()` (introduced in 6.0.0 via [53282]) is deprecated and unused in Core.

**Props note:**
There's a long multiple year history baked into Font Face, which dates back to the early versions of a web font API (see #46370 and [WordPress/gutenberg#41479 roadmap]. The props list includes those who contributed from those early versions up to this commit.

**References:**
* #46370 original (Web)Fonts API proposal for registering and enqueuing web fonts.
* [WordPress/gutenberg#41479 Gutenberg tracking issue] which includes the evolution from Webfonts API to Fonts API to Font Face.
* [53282] / #55567 Added the stopgap code `_wp_theme_json_webfonts_handler()` in 6.0.
* [https://developer.mozilla.org/en-US/docs/Web/CSS/@font-face @font-face on mdn web docs]
* #59166 Font Library: Font manager for WordPress

Follow-up to [53282].

Props aristath, jonoaldersonwp, hellofromTonya, andraganescu, annezazu, antonvlasenko, arena, askdesign, azaozz, bph, bradley2083, colorful-tones, costdev, davidbaumwald, desrosj, dingo_d, djcowan, domainsupport, dryanpress, elmastudio, flixos90, francina, garrett-eclipse, gigitux, grantmkin, grapplerulrich, gziolo, ironprogrammer, jb510, jeffpaul, jeremyyip, jffng, joostdevalk, jorgefilipecosta, juanmaguitar, mamaduka, matveb, mburridge, mitogh, ndiego, ntsekouras, oandregal, ocean90, oglekler, paaljoachim, pagelab, peterwilsoncc, poena, priethor, scruffian, SergeyBiryukov, shiloey, simison, skorasaurus, soean, westonruter, wildworks, zaguiini.
Fixes #59165.
Built from https://develop.svn.wordpress.org/trunk@56500


git-svn-id: https://core.svn.wordpress.org/trunk@56012 1a063a9b-81f0-0310-95a4-ce76da25c4cd
@matiasbenedetto matiasbenedetto mentioned this issue Sep 5, 2023
Closed
@annezazu annezazu added [Feature] Typography Font and typography-related issues and PRs and removed [Feature] Fonts API labels Sep 25, 2023
@annezazu
Copy link
Contributor

Closing this out as https://core.trac.wordpress.org/ticket/59165 shipped. Let me know if that's incorrect and I can reopen. Thanks for all the hard work here!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
[Feature] Font Library [Feature] Typography Font and typography-related issues and PRs [Type] Overview Comprehensive, high level view of an area of focus often with multiple tracking issues [Type] Tracking Issue Tactical breakdown of efforts across the codebase and/or tied to Overview issues.
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests