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

[WordPress Trac]

#46370: Fonts API: a proposal for creating an API to register and enqueue web fonts
------------------------------------------------+--------------------------
 Reporter:  jonoaldersonwp                      |       Owner:
                                                |  hellofromTonya
     Type:  feature request                     |      Status:  closed
 Priority:  normal                              |   Milestone:
Component:  General                             |     Version:
 Severity:  normal                              |  Resolution:  reported-
                                                |  upstream
 Keywords:  needs-testing-info gutenberg-merge  |     Focuses:
                                                |  performance, privacy
------------------------------------------------+--------------------------
Changes (by hellofromTonya):

 * status:  assigned => closed
 * resolution:   => reported-upstream
 * milestone:  6.4 =>


Comment:

 The proposal in this ticket is focused on developing an API for allowing
 the registration and enqueuing of web fonts. As I previously noted in
 comment:146, the direction of fonts has changed to point where an API is
 no longer needed.

 What's coming is a fonts management system with the introduction of:

 * Font Library: a fonts manager for WordPress. See #59166.
 * Font Face: the server-side `@font-face` styles generator and printer.
 See #59165.

 This proposal provided the catalyst for an R&D process that eventually
 evolved into what is coming. It's been a long road with many twists and
 turns as learnings were gained with what was known at each point along the
 way. All of those learnings led to what is coming - a fonts management
 system.

 The original problem statement raised in this proposal will be solved with
 the new fonts management system.

 >Loading custom fonts in a sub-optimal manner can cause significant
 performance and privacy issues. Anecdotally, inefficient font loading is
 frequently one of the biggest performance bottlenecks in many WordPress
 themes/sites.
 >
 >This is, in part, because there hasn’t been a ‘best practice’ approach;
 there’s no ‘standard’ way of adding a font to a theme and ensuring that
 it’s loaded in a performance- and privacy-friendly manner.

 But it will be solved in a different way than proposed in this ticket.
 Thus, I think this ticket can be closed, i.e. in favor of Trac tickets
 previously noted above.

 I also think commits for Font Face (see #59165) should reference this
 ticket and contributors to this ticket should be given contribution props.

 == Learnings

 Fast forward to today. I now realize that introducing the (Web)Fonts API
 into Core would have been problematic. How so?

 === The API caused data problems.

 The API was the entry point for plugins (and classic themes) to present
 their fonts to users for their consideration, i.e. for users to decide if
 they wanted to use any of the plugin fonts globally on their website. It
 did this by injecting registered fonts into a higher level data layer that
 was used in the user interface.

 Then at enqueue time, the API had to reconcile which fonts should be used.
 It was an active but separate participate in figuring out which fonts were
 to be used globally. While higher data levels are responsible for the
 decision making, this API also needed to be involved to know which fonts
 to enqueue and thus print. This caused problems, as I noted in #59165:

 >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."

 === Was not compatible with the Font Library.

 Once the first prototype of the Font Library was presented, it was
 determined the Fonts API was not compatible with it and caused more
 problems such as:
     * plugins would need to register with the Fonts API and the Font
 Library.
     * plugins/themes could bypass the fonts manager via directly enqueuing
 their fonts, without users knowing.
     * font reconcilation process would become even more difficult and
 problematic, likely less stable and prone to inconsistencies.

 It would have made debugging harder and maintaining more costly.

 === Get it out of the decision reconcilation process.

 Previously [https://github.com/WordPress/gutenberg/issues/41479 the Fonts
 API's 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).

 With the new fonts management direction, Role 2 was removed as it was
 covered within the Font Library:
 >Plugins will no longer interact with the Fonts API. Instead, they will
 integrate directly into the Font Library (once that capability exists).

 Shifting the role removed the problems above, including removing it from
 the decision reconcilation process. In doing so, register and enqueue
 functionality was no longer needed. Thus, an API was not needed.

 The vision of font management simplified what was originally the Fonts
 API. Parts of it were reimagined and reassembled, moving what was
 "register" closer to where users interact with those fonts.

 == Summary: this proposal led to a fonts manager.

 All of these learnings along the way, each implementation, led to what is
 coming, which IMO is a better user experience and workflow than originally
 imagined. It was a R&D process.

 Though it's been a long road filled with challenges and opportunities, it
 was the catalyst that eventually evolved into solving the problems raised
 in this proposal.

 Thank you to each contributor! I invite you to stay involved in Font Face
 and Font Library.

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