[wp-trac] [WordPress Trac] #59165: Font Face: Server-side @font-face styles generator and printer

Wed Aug 23 20:45:15 UTC 2023

#59165: Font Face: Server-side @font-face styles generator and printer
-------------------------------------------------+-------------------------
 Reporter:  hellofromTonya                       |       Owner:
                                                 |  hellofromTonya
     Type:  enhancement                          |      Status:  accepted
 Priority:  normal                               |   Milestone:  6.4
Component:  General                              |     Version:
 Severity:  normal                               |  Resolution:
 Keywords:  gutenberg-merge needs-dev-note has-  |     Focuses:
  patch has-unit-tests has-testing-info          |
-------------------------------------------------+-------------------------
Description changed by sabernhardt:

Old description:

> Introducing Font Face, a server-side `@font-face` styles generator and
> printer. This ticket tracks merging Font Face from Gutenberg into Core.
>
> == What is Font Face?
>
> Font Face's role is to generate and print the `@font-face` styles for all
> theme defined and user activated fonts (activation will be handled by
> Font Library #59166).
>
> There is no font registration or enqueuing.
>
> It is not involved in the process of determining which fonts the site
> should or is using. Rather, it processes what is passed to it or, if
> none, pulls / gets the fonts from Theme_JSON's merged data layer.
>
> It introduces a new global function called `wp_print_font_faces()`. This
> function 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).
>
> == What is `@font-face` styles?
>
> Per [https://developer.mozilla.org/en-US/docs/Web/CSS/@font-face mdn web
> docs]:
> >The `@font-face` CSS at-rule specifies a custom font with which to
> display text; the font can be loaded from either a remote server or a
> locally-installed font on the user's own computer.
>
> == Does it work on classic sites too?
>
> Yes. For classic sites, themes and plugins can directly call
> `wp_print_font_faces()` and pass their fonts array to it for processing.
>
> == Does it replace `_wp_theme_json_webfonts_handler()`?
>
> Yes. Font Face is a direct replacement for the stopgap code in
> `_wp_theme_json_webfonts_handler()` that was introduced in 6.0 via
> [53282].
>
> == Is it built-off of Fonts API?
>
> Font Face is built off of the early versions of a Web Fonts API that was
> first proposed in #46370. The internal CSS generation and printing comes
> from that early version.
>
> It does not include register, deregister, enqueue, or custom provider
> functionality.
>
> == Why no register or enqueue?
>
> The earlier versions of a web font API went through many implementations
> to fit what was known in each's time. It involved from Webfonts API to
> Web Fonts API to Fonts API. Each of these APIs provided the means for
> themes and plugins to register fonts with it, these registered fonts were
> injected into Theme JSON theme data layer for presentation to the user
> for selection. And then user selected fonts and theme defined fonts were
> enqueued and printed.
>
> The role of registration existed for the purpose of making fonts
> available for users to globally select what they want on their website.
> Then those selections were enqueued for style generation and printing.
>
> But problems happened with a low level service trying to inject fonts
> into higher data levels. A low level service should not be involved in
> the process of determining what fonts are being used and should be
> generated and printed. Rather, a low level service should be told "Hey,
> process these fonts."
>
> The Font Library (see #59166) changed the direction as its role is to
> present fonts to users for them to manage what fonts they want on their
> website. Users will be able to upload / install, activate, and deactivate
> fonts. Those selections will then be saved for the system to use,
> including Font Face.
>
> == Is it an API?
>
> No. Other components and APIs will not interact with it, per se. Rather,
> it receives or gets what it needs to do its job.
>
> == References:
> * #46370 original (Web)Fonts API proposal for registering and enqueuing
> web fonts.
> * [https://github.com/WordPress/gutenberg/issues/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

New description:

 Introducing Font Face, a server-side `@font-face` styles generator and
 printer. This ticket tracks merging Font Face from Gutenberg into Core.

 == What is Font Face?

 Font Face's role is to generate and print the `@font-face` styles for all
 theme defined and user activated fonts (activation will be handled by Font
 Library #59166).

 There is no font registration or enqueuing.

 It is not involved in the process of determining which fonts the site
 should or is using. Rather, it processes what is passed to it or, if none,
 pulls / gets the fonts from Theme_JSON's merged data layer.

 It introduces a new global function called `wp_print_font_faces()`. This
 function 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).

 == What is `@font-face` styles?

 Per [https://developer.mozilla.org/en-US/docs/Web/CSS/@font-face mdn web
 docs]:
 >The `@font-face` CSS at-rule specifies a custom font with which to
 display text; the font can be loaded from either a remote server or a
 locally-installed font on the user's own computer.

 == Does it work on classic sites too?

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

 == Does it replace `_wp_theme_json_webfonts_handler()`?

 Yes. Font Face is a direct replacement for the stopgap code in
 `_wp_theme_json_webfonts_handler()` that was introduced in 6.0 via
 [53282].

 == Is it built-off of Fonts API?

 Font Face is built off of the early versions of a Web Fonts API that was
 first proposed in #46370. The internal CSS generation and printing comes
 from that early version.

 It does not include register, deregister, enqueue, or custom provider
 functionality.

 == Why no register or enqueue?

 The earlier versions of a web font API went through many implementations
 to fit what was known in each's time. It involved from Webfonts API to Web
 Fonts API to Fonts API. Each of these APIs provided the means for themes
 and plugins to register fonts with it, these registered fonts were
 injected into Theme JSON theme data layer for presentation to the user for
 selection. And then user selected fonts and theme defined fonts were
 enqueued and printed.

 The role of registration existed for the purpose of making fonts available
 for users to globally select what they want on their website. Then those
 selections were enqueued for style generation and printing.

 But problems happened with a low level service trying to inject fonts into
 higher data levels. A low level service should not be involved in the
 process of determining what fonts are being used and should be generated
 and printed. Rather, a low level service should be told "Hey, process
 these fonts."

 The Font Library (see #59166) changed the direction as its role is to
 present fonts to users for them to manage what fonts they want on their
 website. Users will be able to upload / install, activate, and deactivate
 fonts. Those selections will then be saved for the system to use,
 including Font Face.

 == Is it an API?

 No. Other components and APIs will not interact with it, per se. Rather,
 it receives or gets what it needs to do its job.

 == References:
 * #46370 original (Web)Fonts API proposal for registering and enqueuing
 web fonts.
 * [https://github.com/WordPress/gutenberg/issues/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.
 * `@font-face` [https://developer.mozilla.org/en-US/docs/Web/CSS/@font-
 face on mdn web docs]
 * #59166 Font Library: Font manager for WordPress

--

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/59165#comment:12>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform