[wp-trac] [WordPress Trac] #46370: A proposal for creating an API to register and enqueue web fonts

[WordPress Trac]

#46370: A proposal for creating an API to register and enqueue web fonts
------------------------------------------+--------------------------------
 Reporter:  jonoaldersonwp                |       Owner:  hellofromTonya
     Type:  feature request               |      Status:  assigned
 Priority:  normal                        |   Milestone:  5.9
Component:  General                       |     Version:
 Severity:  normal                        |  Resolution:
 Keywords:  needs-patch needs-unit-tests  |     Focuses:  performance,
                                          |  privacy
------------------------------------------+--------------------------------
Changes (by hellofromTonya):

 * keywords:  has-patch has-unit-tests => needs-patch needs-unit-tests
 * owner:  (none) => hellofromTonya
 * status:  new => assigned
 * milestone:  Awaiting Review => 5.9


Comment:

 @aristath and @jonoaldersonwp created a wonderful starting point with
 [https://github.com/WordPress/wordpress-develop/pull/1573 PR 1573]. It
 served to foster discussions and discovery about what this API could be
 now and into the future. It caught my attention and imagination.

 == Learnings and a refined approach

 During this process, thinking shifted to start with the end in mind, i.e.
 supporting `theme.json` for what that schema should be. Defining that
 schema led to thinking about a standardized way to configure one or more
 webfonts within a theme that has `theme.json`, a theme that doesn't, and a
 plugin.
 - How could that schema be standardized for all of these use cases?
 - Could the API have a single entry point for registration to support all
 of these use cases?
 - Could that schema be standardized so that extenders could migrate and
 support different types of products and themes?
 - Could that schema led to further performance boosts?

 This exploration led to a refined approach:

 - A standardized "webfonts collection" schema that works in JSON and array
 format:

 within `theme.json`
 {{{
 {
         "webfonts": {
                 "roboto-normal-400": {
                         "fontFamily": "Roboto",
                         "fontWeight": "400",
                         "fontStyle": "normal",
                         "provider": "google"
                 },
                 "roboto-italic-400": {
                         "fontFamily": "Roboto",
                         "fontWeight": "400",
                         "fontStyle": "italic",
                         "provider": "google"
                 },
                 "my-font-normal-400": {
                         "fontFamily": "My Font",
                         "fontDisplay": "swap",
                         "fontWeight": "400",
                         "fontStyle": "normal",
                         "src": [
                                 "fonts/MyLocalFont.woff",
                                 "fonts/MyLocalFont.woff2"
                         ],
                         "provider": "local"
                 },
                 "my-custom-font-normal-400": {
                         "fontFamily": "My Custom Font",
                         "fontWeight": "400",
                         "fontStyle": "normal",
                         "provider": "my-custom-provider"
                 }
         }
 }
 }}}

 and in an array:
 {{{
 wp_register_webfonts(
         array(
                 'roboto-normal-400' => array(
                         'fontFamily'  => 'Roboto',
                         'fontStyle'   => 'normal',
                         'fontWeight'  => '400',
                         'provider'    => 'google',
                 ),
                 'roboto-italic-400' => array(
                         'fontFamily'  => 'Roboto',
                         'fontStyle'   => 'italic',
                         'fontWeight'  => '400',
                         'provider'    => 'google',
                 ),
                 'my-font-normal-400' => array(
                         'fontFamily'  => 'My Font',
                         'fontDisplay' => 'swap',
                         'fontWeight'  => '400',
                         'fontStyle'   => 'normal',
                         'src'         => array(
                                 get_template_directory_uri() .
 '/fonts/font.woff2',
                                 get_template_directory_uri() .
 '/fonts/font.woff',
                         ),
                         'provider'     => 'local',
                 ),
                 'my-custom-font-normal-400' => array(
                         'fontFamily'  => 'My Custom Font',
                         'fontStyle'   => 'normal',
                         'fontWeight'  => '400',
                         'provider'    => 'my-custom-provider',
                 ),
         )
 );
 }}}

 - The API can handle bundling the providers, registering each, and
 instantiating each when needed

 - As @flixos90 suggested, the API can expose a way to register a custom
 provider, e.g. `wp_register_webfont_provider()`

 - Each provider is configured in the schema via its unique ID or slug

 - As @flixos90 suggested, the API can collect like fonts for optimizing
 processing and external fetching

 - Modern(ish) architecture can be built with:
     - OOP to encapsulate the processing, eliminating the need for private
 global functions and longer functions
     - schema validation
     - parameter input validation:
     - type hinting (where appropriate for the supported PHP versions)
     - type validation with doing it wrong (when type hinting is not an
 option)
     - PHP 8.0 and 8.1 compatibility
     - full unit/integration tests
     - performance testing

 == What about following the existing pattern for enqueue/register?

 While attempting to reuse `wp_enqueue_[script|style]` patterns feels
 familiar, it created complexity and confusion. It's limiting what this API
 could do such as collecting like fonts to make one request to an external
 API for improved performance.

 This is a new API. Starting with the future in mind, this API can be built
 today as a stepping stone to the future.

 == What's the next step?

 The current plan is to create a scaffolding of the new architecture in a
 branch on @aristath fork. I'll start this tomorrow. Existing knowledge
 from the PoC will be ported into it. Everyone is welcomed and encouraged
 to collaborate.

 With this refined approach and `theme.json` need for this, I'm moving it
 into the milestone. Thank you everyone who has been contributing to the
 discussion!

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