| | 32 | == Is it built-off of Fonts API? |
| | 33 | |
| | 34 | 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. |
| | 35 | |
| | 36 | It does not include register, deregister, enqueue, or custom provider functionality. |
| | 37 | |
| | 38 | == Why no register or enqueue? |
| | 39 | |
| | 40 | 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. |
| | 41 | |
| | 42 | 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. |
| | 43 | |
| | 44 | 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." |
| | 45 | |
| | 46 | [https://github.com/WordPress/gutenberg/issues/52698 The Font Library] 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. |
| | 47 | |
| | 48 | == Is it an API? |
| | 49 | |
| | 50 | No. Other components and APIs will not interact with it, per se. Rather, it receives or gets what it needs to do its job. |
| | 51 | |