Font Library: include a system fonts collection by default.

[matiasbenedetto]

What?

Is there a chance to include a selection of operating system font stacks like suggested here? https://github.com/WordPress/twentytwentyfour/issues/175 https://github.com/system-fonts/modern-font-stacks Not be confused with web safe fonts or the usual default serif and sans stacks, here they are grouped by typeface category based on what users have typically installed on their systems using one of the operating systems. OS ship quite a lot of fonts these days and these stacks take advantage of that by categorizing them.

:arrow_up: Originally suggested by @Ren2049 in this https://github.com/WordPress/gutenberg/issues/54169#issuecomment-1706351823

I think we could have a new tab in the Font Library modal featuring these fonts. It would be useful and super-quick to implement due to the Font Library collection API.

Why?

To provide users with a collection of fonts ready to be 'installed' that require no font assets downloads.

Question?

Should we make this part of core or it should be added by a plugin?

[jasmussen]

Good issue, and I'd like a series of stacks like that available, either optionally or by default in the font picker.

However I would suggest this features should not be part of the first version of the library, and in fact it should have a separate interface. I like to think of the font library as a "silo of fonts", similar to how the media library is a silo of images, video, etc. Conceptually thinking of it in that way provides some opportunities to focus and simplify the interface, make it dedicated to font management in a way that might not be as focused if we also add other font settings or configuration. To that end, my instincts would be to have a separate interface for managing font stacks, that isn't part of the "library", but perhaps lives in Global Styles instead.

We might actually discover there that the modal could be the place for it after all, but it needs some visual exploration first, which is another argument here to move a bit slowly.

[LittleBigThing]

For what it's worth, I did test implementing modern font stacks making font stacks available by default, next to the fonts provided by the active theme. The plugin does not work with child themes for now, it's just an idea that could indeed fit in the concept of the Font Library (or indeed 'next to' the possibilities the library provides).

I think providing such stacks could enable users to choose (zero weight) fonts instead of sometimes (unknowingly) overloading their sites with several web fonts.

[luminuu]

+1 for implementing this. I'm currently working on a migration of plugin code to the font library and there's a bunch of pre-defined "websafe" fonts as they're called. They're currently unable to be migrated properly.

[colorful-tones]

It seems counterintuitive to say: we should wait to support system fonts, because they're largely a default fallback option and an ideal performance-friendly approach. However, I feel like it does need a little more thought than adding a tab to the Font Library.

I mostly agree with @jasmussen's observation:

However I would suggest this features should not be part of the first version of the library, and in fact it should have a separate interface. I like to think of the font library as a "silo of fonts", similar to how the media library is a silo of images, video, etc. Conceptually thinking of it in that way provides some opportunities to focus and simplify the interface, make it dedicated to font management in a way that might not be as focused if we also add other font settings or configuration. To that end, my instincts would be to have a separate interface for managing font stacks, that isn't part of the "library", but perhaps lives in Global Styles instead.

We might actually discover there that the modal could be the place for it after all, but it needs some visual exploration first, which is another argument here to move a bit slowly.

It could feel awkward to release the Font Library without a solution in place for system fonts, but I would rather see some design and dialogue about what that looks like, ship the Font Library (as it is), and work towards a solution as a high-priority follow up for WP 6.6.

Of course, with all that said - I've not fully tested the existing Font Library functionality as it stands. It has been a few weeks since I've done this, and I plan to do some thorough testing in the coming days, and look for patterns or gaps for feedback. I'll be sure to drop back and update my thoughts if they change. Thanks! 😄

[jasmussen]

It could feel awkward to release the Font Library without a solution in place for system fonts

To add some nuance there, system fonts work fine and have been for a long time, Twenty Twenty Four offers a couple of stacks:

What we're referring to here, is a UI to manage those stacks. Technically you can even add custom fonts in today's themes, it's just substantially harder, which is why a UI is so important to land, and drastically expand the expression for themes in an intuitive, privacy first, convenient way.

I agree it'd be good to have some solid designs in place for said font stack management, and I'll put together some mockups for that ASAP.

[colorful-tones]

I meant to circle back and close the loop. @jasmussen and I had a chat and I clarified with the following…

To add some nuance there, system fonts work fine and have been for a long time, Twenty Twenty Four offers a couple of stacks

I'm glad you called that out because if some user landed on this issue, did not read through the entire conversation, and needed to be more familiar with existing block theme functionality, they might miss that nuance. I was primarily working off the context of the issue's title: Font Library: include a system fonts collection by default. This implies that we're merely discussing a UI and not that default fonts do not work in WordPress (a la Gutenberg). I know that default fonts work in WordPress today, and I know how to implement them in theme.json. 👍

I feel like it does need a little more thought than adding a tab to the Font Library.

My comment here was directed at Matias Benedetto's screenshot in the Font Library: Font Collection issue (https://github.com/WordPress/gutenberg/issues/57980).

I should have clarified that, and I apologize for the lack of context there. There is no assumption on my part that the screenshot is likely the UI that will be proposed, and even if it was, I would still like to consider it and see what any other folks from the community might say.

Ultimately, I think further design exploration (as already proposed) is a wonderful idea. Thanks!

[jasmussen]

Here's a first draft mockup:

It exists in the Global Styles > Typography panel, intentionally disconnected from the modal, because a font stack can consist of any webfont you can name, as well as custom fonts you upload or add from the library.

This version has the most basic support, it simply adds an input field where you can see the value of the font stack, edit it there.

A slightly more complex version would be to add the beginnings of a key/value pair grid, and/or expand the ItemGroup component, and split the values into a more ergonomic interface:

[colorful-tones]

intentionally disconnected from the modal, because a font stack can consist of any webfont you can name,

My first reaction - bravo and clever, but then I worry that the disconnect will perplex users. They may not trust or correlate the fact that the custom fonts they’ve added in the Font Library are being merged into a prioritized list with the fonts in the Font Stacks sidebar area. That is, I’m assuming that is what is being proposed to happen. However, it would be ideal to clarify this.

I’m now seeing the breadth of the complexity that this “small” feature adds to the overall Font Library.

(Sorry, I’m on mobile and keeping feedback brief right now and will try and circle back.)

[getdave]

Reading through the discussion here it seems like:

• it's possible to use system fonts in WordPress today. That's a ✅
• what we're referring to in this Issue, is a UI to manage system font stacks (example).
• it's unlikely that a UI to manage font stacks will be added to the Font Library feature as slated for WP 6.5.
• contributors are actively looking to create such an interface for a future (i.e. post-6.5) release, but expanding the current feature set of the Font Library feature this close to WP 6.5 Beta 1 is unlikely to happen.

@jasmussen @colorful-tones Have I understood this correctly? If so can we remove this from the 6.5 board? If not, please could you let us know how/why? Many thanks 🙇

[colorful-tones]

Have I understood this correctly? If so can we remove this from the 6.5 board? If not, please could you let us know how/why? Many thanks

Yes, I believe you've captured the essence of where the discussion has landed. Yes, I agree we can likely remove this from the 6.5 board. I just posted the Editor Triage and this task is on it, and I believe it'll likely get voted by all to be moved off the board. I say let's wait for voting to finalize and I'll likely be the one circling back to triage this item off the board. Thanks all!

[matiasbenedetto]

Thanks for adding these mockups https://github.com/WordPress/gutenberg/issues/54186#issuecomment-1923393213

They are a good step forward in managing fonts in the editor. Still, something doesn't feel right: the distinction between "Fonts" and "Font Stacks." Why? because, as you said:

a font stack can consist of any webfont you can name, as well as custom fonts you upload or add from the library.

All fonts are actually font stacks on the web. Fonts can have one or more fallbacks explicit or implicit. Look at the explicit fallbacks of the Google Fonts collection as an example. Considering this, why should we have two different lists of fonts ("Fonts" and "Font Stacks")? That distinction may seem artificial and puts on the user the burden of knowing what the technical differences between those lists of fonts are. Having only one list of fonts may be clearer and abstracts the user from knowing the technical details of how fonts work in a browser making the process transparent for them.

From that list, the user should be able to select the fonts to edit. As in the mockups provided, the UI will allow the user to edit the font 'stack', which is just one way of calling the CSS font-family property. This UI, probably in the future, should allow the user to edit other advanced font-face-related configs that are already available in theme.json but don't have a UI to manage them visually.

[LittleBigThing]

I agree with @matiasbenedetto that having fonts and font stacks adds a layer of complexity. I appreciate the flexibility of building font stacks, but I think that someone who has an understanding of how fonts are set and loaded on the web, would be able to use theme.json or a font collection to add font stacks.

IMHO system fonts could be a predefined font collection, provided by core.

For example as ‘Local Fonts’ (as provided by this plugin):