Global Styles/Typography: Managing fonts

[jasmussen]

Fonts and font weights can be defined in theme.json in settings.typography.fontFamilies.fontFace.

See example code

``` { "fontFace": [ { "fontFamily": "DM Sans", "fontStretch": "normal", "fontStyle": "normal", "fontWeight": "400", "src": [ "file:./assets/fonts/dm-sans/DMSans-Regular.woff2" ] }, { "fontFamily": "DM Sans", "fontStretch": "normal", "fontStyle": "italic", "fontWeight": "400", "src": [ "file:./assets/fonts/dm-sans/DMSans-Regular-Italic.woff2" ] }, { "fontFamily": "DM Sans", "fontStretch": "normal", "fontStyle": "normal", "fontWeight": "700", "src": [ "file:./assets/fonts/dm-sans/DMSans-Bold.woff2" ] }, { "fontFamily": "DM Sans", "fontStretch": "normal", "fontStyle": "italic", "fontWeight": "700", "src": [ "file:./assets/fonts/dm-sans/DMSans-Bold-Italic.woff2" ] } ], "fontFamily": "\"DM Sans\", sans-serif", "name": "DM Sans", "slug": "dm-sans" }, ```

There isn't yet a user interface for it. Here are mockups to explore how you should be able to add fonts. The main interface for managing fonts would live in Global Styles → Typography, where a plus button would let you add a font from Google Fonts:

Note importantly that before you connect to Google fonts, you have to give consent to allow that connection to happen, as shown in the mockup above. If you have feedback on the copy, please share it, the consent box can be as verbose as it needs to be.

The modal is to be considered a "Font Library" and behaves just like the image media library, in that it is a silo of fonts, both those you have uploaded manually, or added from Google. But the sidebar list of fonts shows only the subset that are active and available to choose in your font pickers (and saved to theme.json). In that vein the checkboxes for each font weight also denote which fonts are "active":

There's a separate Upload tab:

When there are no fonts installed, there should be a bigger button to open the fonts dialog:

---

This issue was updated Aug 30.

Earlier version that were inline in the sidebar

But there isn't yet a user interface for it. Here are mockups to explore how you should be able to add fonts. The main interface for managing fonts would live in Global Styles → Typography, where a plus button would let you add a font from Google Fonts: Uploading fonts would be available from the same interface, featuring a dropzone also serving as an upload button: This same interface would also allow you to select or unselect font-weights used: The above three mockups would round out the main tasks for additing and managing fonts and their weights. Separate explorations could include an upgraded font picker for selecting fonts featuring a visual preview: Here's also an early draft at how to manage variable width fonts: There are a number of open questions still to be explored around how variable width fonts are best leveraged, and the files themselves allow for many interesting effects, including animated transitions. For now, this mockup simply treats it as a source of virtually infinite font weights that can be leveraged.

Initial proposal

Let's surface an interface both for picking font sets (a primary font for headings and a secondary font for body text), as well as for managing the set properties. It could live in Global Styles → Typography: * The active font set is shown with a dark border * Choosing "Default" in font picker dropdowns would leverage either the primary (headings) or the secondary (body + other text) fonts of the active set. You'd be able to manage font weights: * To edit a set, click "Edit" then choose the set * Click the plus next to existing chosen font weights and pick in a modal If you are starting from scratch and have no defined font weights, only a plus to add a new font is shown: * System font is an option from the dropdown, in addition to a few other basic webfonts (such as `sans-serif`, `serif`, or `monospace`) * When web fonts are used with no attached font file, no weight picker is present, showing instead "Default weights" You can use just a single font as both primary and secondary: * The `Aa` font preview shows the capital A in bold, denoting the primary font, and the lowercase a in regular font weight, denoting body text, and matching default browser values. A basic interface for uploading fonts can be found in the ellipsis menu: This upload interface assumes that font metadata such as _name_, _style_, and _weight_, can be extracted and applied to the font-face definition. If this is non-trivial, we can surface separate input fields for these values: A library for managing uploaded assets like these can be explored separately, and linked here.

[javierarce]

I think it would be possible to parse the font files to extract the name and the style (at least, I know this is true for ttf and otf, which I think we could include on that list).

If we could have that, then the upload flow could be more simple: users upload a file and then we expose the metadata on a second step (perhaps there's no need to let users customize the font details).

[javierarce]

Also, aren't font style and font weight the same thing? 🤔

[jasmussen]

users upload a file and then we expose the metadata on a second step (perhaps there's no need to let users customize the font details)

Nice, that seems ideal. If that seems feasible in implementation, probably the path to lean towards.

Also, aren't font style and font weight the same thing? 🤔

They are combined in a single "Apperance" menu in the UI, and should remain as such, but in case we aren't able to extract these properties as metadata, CSS-wise the font definition does need separate values for font-style and font-weight, to match the theme.json counterparts:

        {
            "fontFamily": "DM Sans",
            "fontStretch": "normal",
            "fontStyle": "italic",
            "fontWeight": "700",
            "src": [
                "file:./assets/fonts/dm-sans/DMSans-Bold-Italic.woff2"
            ]
        }

I.e. the above would show up as a single "Bold Italic" option in the apperance menu.

All the more reason to extract metadata if we can.

[jameskoster]

This is looking really good already. A couple of smaller points:

The plus icon next to font weights kind of suggests that it's only possible to add weights, not remove them. Maybe a different icon, or even the same 'EDIT' button you have next to Fonts in the typography panel could work?

In the weight management modal, I know it's covered in the description, but should we also display a warning when x kb of weights are selected? Similarly, what happens if all weights are unselected, disable the save button?

In the Typography panel of block settings, I think it might be useful to also include whether the current settings is Primary or Secondary.

Should there be a way to add a tertiary font?

[jasmussen]

The plus icon next to font weights kind of suggests that it's only possible to add weights, not remove them. Maybe a different icon, or even the same 'EDIT' button you have next to Fonts in the typography panel could work?

I'm missing a beat, can you expand a bit? Here's the figma btw.

In the weight management modal, I know it's covered in the description, but should we also display a warning when x kb of weights are selected?

I think @javierarce mentioned this in a chat I had with him as well. Yes, it'd be nice to make the "careful with font weights" warning contextual to the filesize. I omitted that for now as I'm unsure how complex it would be for a developer to do this, and to keep things simple. But if easy, would be nice.

Similarly, what happens if all weights are unselected, disable the save button?

👍 👍

In the Typography panel of block settings, I think it might be useful to also include whether the current settings is Primary or Secondary.

Instead of just showing "Default"? Interesting. Can we do this in a back compat way, for any block settings that currently rely on having "Default" selected?

Should there be a way to add a tertiary font?

Big maybe. I'd lean towards not. You can already add as many fonts as you like through an upload interface, and they'd then be available in any font family dropdown on a per-block basis. By limiting to primary and secondary, the idea is that we can apply those across headings and body text when activating a pairing. A pairing of three fonts would apply to headings, body text and then what would the third one cover?

[jameskoster]

I'm missing a beat

Apologies, I meant this one:

If I want to remove a weight, the + doesn't really indicate that action very clearly. I was wondering if we could use the same 'EDIT' button from the main Typography panel:

Or perhaps a different label: "Add/remove", or just a different icon?

---

Instead of just showing "Default"? Interesting

Ah not instead, in addition to. It might be useful to be able to confirm that the default is correct. IE paragraphs are using Secondary rather than Primary.

---

then what would the third one cover

I was thinking about if you might want to upload a custom monospace icon for code blocks, but I didn't account for

You can already add as many fonts as you like through an upload interface

If that's the case then two seems like the best place to start 👍

[jasmussen]

If I want to remove a weight, the + doesn't really indicate that action very clearly. I was wondering if we could use the same 'EDIT' button from the main Typography panel:

Ah, yes, that makes sense.

Separately, I think there may be room in the icon set for a small version of the "Edit" icon, one that shares DNA with the plus and the minus, in size as well.

Ah not instead, in addition to. It might be useful to be able to confirm that the default is correct. IE paragraphs are using Secondary rather than Primary.

Ah. Any preference between first and second column here?

I was thinking about if you might want to upload a custom monospace icon for code blocks, but I didn't account for

Ah, good use case. I think we can probably easily scale this up to a tertiary if the need becomes clear after the first iteration. What do you think?

[jameskoster]

Any preference between first and second column here?

I was thinking along the lines of the first column. It seems most important to know that you're using the primary/secondary font from global styles, rather than knowing the actual family.

I think we can probably easily scale this up to a tertiary if the need becomes clear after the first iteration

👍

[jasmussen]

Thanks for all the feedback. I've updated the issue and added the "Needs dev" label! 🎉

[matiasbenedetto]

:wave: Hi! I built a little prototype before knowing about this proposal. I just read about this so I'm sharing the prototype here. It is inspired by the work that I and other colleagues made for Create Block Theme plugin.

This prototype implements 2 new sections in the Typography part of Global Styles. The new sections are Theme Fonts and Global Fonts.

The Theme Fonts section is intended to be used to inspect the fonts provided by the active theme. In this prototype, the theme fonts are not intended to be manipulated (for example removed) because I think those kinds of changes over the theme-provided config can be difficult to understand, for example: should they be persisted across theme switches?

The Global Fonts section is intended to be used as the user font manager. In this section, the user will be able to add and remove font families and font faces from various sources (the prototype showcases just Google fonts and local fonts but we could add other providers too).

The fonts added here will be persisted in the WordPress instance and won’t depend on the theme. I think this is in line with the Gutenberg direction around having simpler themes and giving more power to the user via the editor.

https://user-images.githubusercontent.com/1310626/200089122-8303d888-35f9-4af2-9034-56ece29b1e44.mp4

[jasmussen]

Nice! Lots to like there.

I don't think we can add Google Fonts integration here, and I think we can put Upload in a modal, but for the overall functionality it seems like there's potential to meet halfway here. Do you have a PR handy? I'd be happy to jump in and help.

[luminuu]

Wouldn't it also be a good idea to have a separate admin page or a bigger modal (like for the settings) to view/edit/upload custom fonts, like in the Create Block Theme plugin? Just like @carolinan mentioned it here: https://twitter.com/carolinapoena/status/1590207811681935362

I feel like the fonts should not be squished into the right sidebar of Gutenberg.

[jasmussen]

Yes, I think there's an opportunity to do that, potentially as part of #45346, which explores moving the Styles tab to the left. That would afford opening a fonts management screen just like there's a templates screen. It would need a little exploration, and I like to think we can start with a modal, but it makes sense.

[jffng]

This is exciting and I think most of this looks great.

Let's surface an interface both for picking font sets (a primary font for headings and a secondary font for body text)

I understand there is meaningful precedence to the idea of font pairings, but it's giving me some pause for the initial iteration of managing fonts. To make sure I understand the intention of the pairings — does this mean that only one "set" can be active at a time? Or that one set is the default, and if there are more fonts, they are still available to choose from at the block level?

In general, I think the pairings / "sets" are an abstraction that are potentially useful and introduce design sensibilities at the top level, but also could create added complexity and cognitive burden. By default, I have to understand that one font will be applied for certain elements and a different font for all others, creating two "defaults" in addition to any other fonts I have defined. Granted these can be the same font, but the application of those fonts feels a bit opaque:

Have you considered an approach that just allowed folks to upload fonts individually (as you already have designed), and allow for one font family to be the default? I don't think the main UI needs to look that different than what you have now, but the specimen would show Aa of a single font family rather than a pair. This wouldn't preclude more savvy users from changing certain elements like headings to be a different font, since those affordances already exist.

And apologies in advance if I'm misunderstanding the design!

[jasmussen]

Those are good thoughts, thanks for sharing.

In terms of font pairings, I think it makes sense mainly for headings (primary) and everything else (secondary), so we can provide some smart defaults that allows minimal customization required for users. For example, I would expect all the following blocks to have their font updated when changing the primary font:

• Heading
• Site title
• Post Title
• Comments Title
• Query Title

Potentially even more, like Pullquote. Similarly, everything else would default to the Secondary font defined. The idea being, I update the two fonts in a single unified place, and all blocks across your site respond to that. So it's essentially an ambiguation of what exists today, which is this:

only, instead of the above applying to both Paragraph and Heading alike, needing me to customize all the aforementioned heading blocks, there are newer smarter defaults for the two archetypes.

Would it help if instead of "Default (Primary)" we did something like this?

Have you considered an approach that just allowed folks to upload fonts individually (as you already have designed), and allow for one font family to be the default? I don't think the main UI needs to look that different than what you have now, but the specimen would show Aa of a single font family rather than a pair. This wouldn't preclude more savvy users from changing certain elements like headings to be a different font, since those affordances already exist.

This would be close to what we have today, right, but only with this default font applying to everything, including all Heading type blocks?

So the hope is to build on this, but have a single place to change heading fonts, instead of 5 different places in GS → Blocks.

[matiasbenedetto]

Building this prototype I stumbled upon this question:

Do we have a truly-global styles/settings way to persist the custom font data (new fonts added) in a theme.json fashion? Do we need to implement infrastructure for it?

Considering that this manager should allow the user to:

• Add and remove font assets and font definitions.
• Persist these settings on the site independently of the theme activated.

Current infrastructure: Gutenberg settings are structured in 3 levels:

• WordPress default settings
• Theme settings
• User settings

Currently, all the settings modified by the user are stored in the user settings level and merged with the previous two levels. The global styles/settings infrastructure is pegged to themes. All the customized global styles or settings are lost if you switch themes. For example, if you select a red background for your site and switch themes, the red background will be gone. This limitation seems to be a blocker for the implementation of a feature like the Gutenberg Font Manager.

Are my considerations right? Should we work on the infrastructure needed to store the new fonts independently of the themes?

[colorful-tones]

Has there been any consideration for variable fonts and font-weight values like font-weight: 118; 🤔

[jasmussen]

Do we have a truly-global styles/settings way to persist the custom font data (new fonts added) in a theme.json fashion? Do we need to implement infrastructure for it?

Good question, I've added a tag to hopefully elicit a good response for now, and we can expand the ping range if no responses land soon.

Has there been any consideration for variable fonts and font-weight values like font-weight: 118; 🤔

Serendipitously, I just found a need to look into this! So I have on my todo list to refresh these mockups with an interface for controlling that. I've a bit on my plate so I'm not sure it'll be next week, and of course the Figma is public.

[fabiankaegy]

Maybe the new Stepped Range Slider as used in the Spacing Preset Slider could be used for the font weight values. By default it just has the steps between 100 and 900 with increments of 100. But you could always toggle to the fine grain control where you can enter manual values.

[noisysocks]

I'll look into implementing this.

[noisysocks]

Do we have a truly-global styles/settings way to persist the custom font data (new fonts added) in a theme.json fashion? Do we need to implement infrastructure for it?

No, we don't have any way to persist this right now. Will need to do some investigation but I imagine some new endpoints may be required.

For example, if you select a red background for your site and switch themes, the red background will be gone. This limitation seems to be a blocker for the implementation of a feature like the Gutenberg Font Manager.

Why is this a problem? Currently user customisations to the theme styles are not carried forward if you switch theme. I don't imagine user customisations to the font sets would be any different.

[matiasbenedetto]

I'll look into implementing this.

@noisysocks I'm currently working on this. I haven't assigned me the ticket because I'm partiallty afk this week.

[noisysocks]

Ah sorry, all yours then. I'll assign you so that it doesn't appear unclaimed in https://github.com/orgs/WordPress/projects/56.

[simison]

This upload interface assumes that font metadata such as name, style, and weight, can be extracted and applied to the font-face definition

Perhaps better as a follow-up, but script support could be a good addition in various font interfaces.

See e.g. Google Fonts:

[annezazu]

@matiasbenedetto curious if you can link to a draft PR so those of us managing updates on this work can be aware? Thank you!

[matiasbenedetto]

@matiasbenedetto curious if you can link to a draft PR so those of us managing updates on this work can be aware? Thank you!

Yep, I submitted the first draft here: https://github.com/WordPress/gutenberg/pull/46332

I continued using the type of interface I implemented for my first prototype instead of the designs from here because I had that already implemented, but much more important than that, I think is clearer and has more visual hints. I would like your input on that.

[annezazu]

Awesome, thank you! Curious what @WordPress/gutenberg-design thinks on that front 👆🏼

[simison]

@matiasbenedetto @jasmussen one of the (many!) exciting aspects of the above PR is fonts shown as they appear, instead of system font. That's not trivial at all to do in performant way for lots of fonts, across all OSes/browsers/languages.

Versus currently in Gutenberg:

Would it be worth extracting just that font visualizing capability and ship it as an improvement to the current list?

With CustomSelectControl being more robust than previously (if I recall right) it should be possible now to have something more similar to Google Docs:

[jasmussen]

For folks subscribed, there are some fresh mockups in https://github.com/WordPress/gutenberg/pull/46332#issuecomment-1367245772, which are partially in an exploratory state, partially in response to learnings from the implementation work. While the mockups don't replace the font pairing aspect of this issue, they will nevertheless likely inform their direction once we're able to get to that.

[jasmussen]

Taking a stab at another refresh that simplifies a little bit, notably making Upload just a link, and changing the appearance of fonts in the inspector with a rendered preview in the main view. Let me know your thoughts and I'll update the issue.

Managing font weights:

Adding fonts from Google:

Uploading fonts:

CC: @matiasbenedetto

[annezazu]

These look awesome! My only comment (and I'm no designer) is that the font names feel like they are floating in the interface a bit strangely, especially when compared to the Elements section:

I both know we need to distinguish them and think it would help to have some consistency potentially. It's not super clear you can click to make changes to them. Perhaps adding the same > icon would help?

[jameskoster]

Nice work, this looks good.

I'd +1 Anne's suggestion about trying ItemGroup for the font list.

It would be nice if there was a quick way to remove a font. Possibly a 'Deselect all' link in the weights list, or a – button in the main list (probably with an 'Are you sure?' dialog)?

A potentially naive question: do we need the inputs in the upload form, is that data not bundled in the font file? It would be really nice if we could handle those details automatically to avoid errors, or inconsistent naming.

[jasmussen]

is that data not bundled in the font file?

Perhaps a good question for @matiasbenedetto ?

[matiasbenedetto]

is that data not bundled in the font file?

Perhaps a good question for @matiasbenedetto ?

Yes, we can get that info from the file asset. We are doing that in Create Block Theme plugin. The inputs are filled automatically by reading the font file, but the user is still able to customize it. I'm not sure if that's necessary or if we are adding an unnecessary potential error surface.

Screencast from 18-04-23 13:14:22.webm

[jameskoster]

Nice!

I'm not sure if that's necessary or if we are adding an unnecessary potential error surface

That was my concern. I think it's a good question to answer: what is the argument for allowing users to edit these details?

[jasmussen]

Here are a slew of fresh mockups based on your feedback. You still customize weigths of existing added fonts in Global Styles > Typography, but can now toggle all or untoggle all using the box at the top right:

Adding fonts happens in a segmented two-pane setup, and font appearances are item-grouped:

The segmented control lets you choose an Upload tab, where you can either click the upload button top pick a file, or drop your file in the zone in the middle:

As an adjacent but relevant to the conversation mockup, I explored what the font picker might look like. Shown here as a flyout where each font is a preview of itself:

Finally, it would be good to start thinking about variable width fonts. The following is a very early draft that doesn't really capture the breadth of what is possible with variable width fonts in terms of animation, but the idea is to un-empty the canvas in case it inspires better ideas. We might find simply creating a custom weight, as shown here, is sufficient, and that any transitional effects interpolate between two chosen weigths?

[jameskoster]

Nice, this feels pretty close to me. Just a couple of minor points:

I appreciate the "Weights" checkbox to quickly select/deselect all, but do you think there should be a shortcut / more obvious way to quickly remove a font from the font list itself?

In the add fonts panel:

• Should the search input be beneath the segmented control? I assume it has no purpose in the Upload UI.
• Should the segmented control be tabs? I feel segmented controls are for settings (like font size), and tabs are for toggling the visibility of different UI's.
• Spacing looks a little large in the upload UI.
• Instead of an Upload button, could there be a drop-zone/button combo so users can just drop files into the browser? The help text could be inside that element.
• Where are you taken after the font is uploaded, back to the font list? Should it be possible to delete an uploaded font there?

Font picker with preview is nice, could perhaps use a search input for when the list is long.

[jasmussen]

I appreciate the "Weights" checkbox to quickly select/deselect all, but do you think there should be a shortcut / more obvious way to quickly remove a font from the font list itself?

Yes, good call. I.e: what happens when you uncheck all? Does it disappear when you go back? Implicit in the mockups is that we allow a transient state where you've added the font, but not yet selected any weights. Transient in that if you do this, click back, save, reload, the font is gone unless you added those weights.

But it might be useful to have a single button at the bottom: Delete?

Should the search input be beneath the segmented control? I assume it has no purpose in the Upload UI.

Yes it probably should:

Should the segmented control be tabs? I feel segmented controls are for settings (like font size), and tabs are for toggling the visibility of different UI's.

I think the semantics can be discussed. IMO form controls can be shown or hidden based on the segmented control state, just like you could show or hide some options based on a selected radio.

In this case I'd mostly like to avoid tabs, because we have so many tabs everywhere, and they usually come with separators that span the full width of the inspector, splitting in two where it needn't be.

I like the segmented control because the singular action it groups is "Add fonts", and makes it agnostic between Google and Upload. It's not the strongest opinion in the world, I might even be easily swayed if we had a tab system that didn't add the horizontal separator also.

Spacing looks a little large in the upload UI. Instead of an Upload button, could there be a drop-zone/button combo so users can just drop files into the browser? The help text could be inside that element.

Good idea. How about this?

I don't actually love that dropzone appearance, but the idea is to use the same component as the Featured image panel.

Where are you taken after the font is uploaded, back to the font list? Should it be possible to delete an uploaded font there?

I would expect you to be taken to the "Weights" page. This is also where you'd be able to deliniate weights in a variable width font in the future. If you uploaded multiple, you'd see multiple checkboxes, if you uploaded one at a time, they'd all group together under the same font name. What do you think?

Font picker with preview is nice, could perhaps use a search input for when the list is long.

Could work:

Thanks for the feedback. What do you think?

[jameskoster]

But it might be useful to have a single button at the bottom: Delete?

Yes I think that works well. In terms of behavior, do you see unchecking all weights then clicking back as the same as deleting? Or would it be possible to have a font installed, but with no weights active?

Everything else looks great! 🚀

[jasmussen]

Yes I think that works well. In terms of behavior, do you see unchecking all weights then clicking back as the same as deleting? Or would it be possible to have a font installed, but with no weights active?

Really good question, and I imagine we might need to ask @matiasbenedetto for input here. My instinct is that unchecking doesn't delete the weights, it just marks them unused. But alternatively, unchecking marks the font file for deferred deletion — i.e. it queues the delete action to the save hub, so when you save/publish, that's when it gets deleted.

Thank you! I'll go ahead and update the issue.

[jasmussen]

For folks subscribed, I've updated the issue here with the newest iteration of mockups. These are all focused primarily on simply adding fonts for usage.

[annezazu]

After some feedback in the FSE Outreach Program around managing fonts with the Create Block Theme plugin experience, I wanted to note that we should update the Styles Welcome Guide to refer to managing fonts when this is merged, perhaps as a new panel.

[jasmussen]

It could also be a temporary notice, like we added for the split inspector:

47410

[annezazu]

When I saved and returned to the previous screen a “System font” was added as well. How would I go about specifying a fallback font? Eg I normally use “Helvetica, Arial, sans-serif” as fallbacks for font-family – I guess this is only possible via custom CSS?

This feedback came in from the FSE Outreach Program once more for Build a Block Theme. Is the plan for fonts selected here automatically adding fallbacks into theme.json?

[jasmussen]

This feedback came in from the FSE Outreach Program once more for Build a Block Theme. Is the plan for fonts selected here automatically adding fallbacks into theme.json?

Given recent conversations on the underlying scaffolding, I thin @oandregal or @matiasbenedetto may be better qualified to answer that question.

On system fonts specifically, it seems useful to either have that option permanently available, or easy to add with a single click, as the font stack can be as long as this:

font-family: -apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ubuntu,Cantarell,"Helvetica Neue",sans-serif;

But as far as font fallbacks for any Google fonts that are added, I wonder how much of this we can do automatically? I.e. can we detect if the font is a sans serif, a serif, or a monotype, and then add sans-serif, serif, monospace as fallbacks, at a minimum? We may end up needing a UI for it, but it would ideal if much of that stack setup could be automated.

[matiasbenedetto]

Updates about this: Due to the need of maintaining the fonts across the switches, we tried an approach for persisting data on the site level in this PR https://github.com/WordPress/gutenberg/pull/50102.

There is no certainty about that is the right move to persist the fonts across switches. So I'm exploring an alternative, instead of using the global settings to persist the site fonts, to create an ad-hoc font library in the database.

This is crucial for this functionality because the UI will necessarily be impacted by the data persistence.

I'm working on a new PR adding the fonts library.

[matiasbenedetto]

But as far as font fallbacks for any Google fonts that are added, I wonder how much of this we can do automatically?

@jasmussen the fallback fonts for google fonts can be guessed by the font category.

[jasmussen]

the fallback fonts for google fonts can be guessed by the font category.

That sounds great, let's do that!

[matiasbenedetto]

I'd appreciate if you can take a look at this new iteration around font management: https://github.com/WordPress/gutenberg/pull/50927

[jasmussen]

June 1st, I've updated this issue with fresh mockups that leverage a modal, hopefully getting us closer to the PR in #50927. It is crucial we stay nimble and land a version of that PR ASAP, even if it isn't perfect to the mockups. In that light, I would recommend we start with as little as possible, and only add back features when it's clear we need them. Simple modal with tabs, adding, activating, deactivating, and postpone any previewing stuff for future explorations.