[Fonts API] Do not expose registered fonts in block settings (only expose enqueued fonts)

[zaguiini]

What problem does this address?

Right now, the Fonts API is exposing registered fonts in the typography picker. That is fine for Site Editor's (Global Styles > Typography UI), but block settings should not see them.

There are 3 places where font families are relevant:

• global styles font presets (this doesn’t have a UI in core yet);
• global elements & block types;
• block instances.

The first two (which represent the global styles UI) should be able to read and select from all registered fonts. Block instances (i.e. selecting a paragraph block in a post), on the other hand, should only get access to fonts enabled through the previous two UIs (presets, elements, and block type enabled font families).

[hellofromtonya]

Right now, the Fonts API is exposing registered fonts in the typography picker. That is fine for Site Editor's (Global Styles > Typography UI), but block settings should not see them.

There are 3 places where font families are relevant:

• global styles font presets (this doesn’t have a UI in core yet);
• global elements & block types;
• block instances.
  The first two (which represent the global styles UI) should be able to read and select from all registered fonts. Block instances (i.e. selecting a paragraph block in a post), on the other hand, should only get access to fonts enabled through the previous two UIs (presets, elements, and block type enabled font families).

Double checking before work begins.

@mtias In the Site Editor, should a user be able to select a registered font-family in any of the Font pickers?

I had thought users could only select at the whole site "custom styles" level:

But at the template level in the Site Editor, there's also a Styles icon for each block. For example, users are currently able to select any "registered" font-family at the block level for a specific template. Should they be about to do this?

[mtias]

@zaguiini is generally correct. Users should be able to select from registered fonts in the context of theme.json, and should be selecting from theme.json reduced fonts in the context of block instances.

The Global elements and block types is slightly more blurry in terms of mechanics. For example, it should be clear what fonts are already in use, but you should still be able to add new ones, which should modify the theme.json set of fonts. This might be a case of discovery more than allowing all registered fonts to show. I'm fine iterating on that middle layer provided everything else works as expected.

[hellofromtonya]

Okay thank you @mtias. That answers my questions in terms of what a user can select in the Site Editor itself.

What about in say a post, i.e. not in the Site Editor? Let me explain my question and thinking.

Enqueued fonts = all theme defined fonts (defined in a theme's theme.json file) plus all user-selected fonts (including plugin registered fonts that a user selected) plus any fonts a plugin directly enqueues (regardless if a user selected them or not in the Site Editor)

When editing/creating a post, should each block's Font picker be a list of all those enqueued fonts? Or should the list be the theme defined fonts + any user selected font for the respective block (meaning each block potentially has a different list)?

If all the enqueued fonts populate all Font pickers in all blocks, then a user has the ability to override the global font selected for a block in the Site Editor.

@mtias what do you envision for font selection in a post editor for each block?

[hellofromtonya]

Update:

This issue is no longer valid for the Fonts API once the Font Library is merged.

Why?

The decision of what fonts to show in the font pickers will reside in theme.json. The Fonts API will no longer add / inject fonts into theme.json, but rather will become read-only of the theme.json merged data.

Issue #51151 supersedes this issue for what to display in the font pickers. Thus, I'm closing this issue and its associated PR.