Use generic font family slugs

[richtabor]

We should consider using more generic font-family slugs (i.e. body, heading, etc) instead of slugs that are specific to the font family that is registered within settings.typography.fontFamilies.

The fonts loaded within settings.typography.fontFamilies are only available on the active style, resulting in CSS variables

Why:

If a the parent theme.json file registers a font, like DM Sans, and uses a slug of dm-sans — whenever we switch styles we're left with an undefined CSS variable output wherever we used "fontFamily": "var(--wp--preset--font-family--system-font)".

Also resulting in none of the parent theme.json's font family values will carry over to subsequent styles.

Below is a screenshot of the CSS generated if you have a specific font-family slug from the parent theme.json that is not available (different font) from a style variation.

Proposal:

Instead if we used body and heading slugs, then those CSS variables will be meaningful within other style variations. A heading with "fontFamily": "var(--wp--preset--font-family--heading)", assigned to it, still maintains the style variant's fontFamily that has the slug of heading.

Having a style that actually inherits the parent style seems the best foot forward in my opinion. And even if we end up not having fontFamilies within the parent theme.json, we should still have these consistent values across the theme — from variation to variation. Example: if I choose my theme's heading font (DM Sans) then switch styles, then that style variation's heading font should take over wherever I used the previous one.

What do you think?

Screenshot:

[colorful-tones]

I support this endeavor! 💯 🥳

[pbking]

I'm just throwing spaghetti here;

What if we both allow users to use any of the fonts included while also allowing the variation to dictate which go where by default?

Say we include all available fonts in the base theme. Therefore, any variation would have a specific font should the user choose one.

Any of those fonts can be mapped to a (Body) or (Header) font by the variation. Should the user choose those options then their choice reflects whatever the variation dictates.

Consider:

{
  "fontFamilies": [
    {
      "name": "DM Sans",
      "slug": "dm-sans",
      ...
    },
    {
      "name": "(Body)",'
      "slug": "body",
      "fontFamily": "var(--wp--custom--fontFamilies--body)
    }
    ...
    {
      "custom": {
        "fontFamilies": {
          "body": "DM Sans",
          "header": "Cabin
      }
      "typography": {
        "fontFamily": "var(--wp--preset--font-family--body)"
    }

[colorful-tones]

@pbking your suggestion is definitely worth exploration, but I would make sure it works with the current webfonts APIs. The theme.json is going to get huge, but meh. 🤷

[colorful-tones]

I guess I'm curious about the expectations around the relationship between the parent theme.json and submitted style variations. If we include fonts in the parent theme.json and say all style variations have to use only the fonts in the theme.json then it may be too restricting. It may be a welcoming design restriction though. 😄

The overall theme would get out of control if all style variations could use their own custom font and we would have to discuss how to break things up if we go down that road, but worth clarifying expectations a bit.

[colorful-tones]

I’ll be curious to see how and where we take the infrastructure here for parent and child style variations.

Perhaps it would be warranted to have TT3 take on the following order:

• TT3 theme - with 2-4 style variations, and
• TT3 child theme - with a handful of community-contributed style variations

This organization would cut down on overall package size and allow style variations to leverage their own custom fonts. Of course, we should still provide some guidelines on maximum overall font size.

A lot of this discussion is beyond the boundaries of the original Issue and I’m happy to spin up another Issue to continue the conversation around theme expectations. 🙏

[pbking]

The more I think about this the more I'm of the opinion that the fonts should remain "Descriptive" rather than "Semantic" (which feels odd, I'm usually Mr. Semantic Champion).

The opinion as to what "headers" are could vary. Is that just heading blocks? Post Titles? Site Title? That decision feels a lot like opinion that belongs in the variations.

Rather, considering that the base theme actually only uses one font family I think that it would be better to have variations customize (at a minimum requirement) the styles.typography.fontFamily value as a user would. One font, one place. And should that variation customize any particular block differently (headers, buttons, post-titles, etc) then it is within its ability but not required.

And while I believe that the variations that ship with the default theme should all ultimately depend of resources bundled with the theme I would also love to see the ability to also leverage variations that can use remotely provided fonts WordPress/gutenberg#43189.

[colorful-tones]

I'm not tied to either the descriptive or semantic slug names, but mostly towards functionality and application. I.e. I'm open to any other slug names.

I think the current suggested naming convention from @richtabor likely stems from historical web design. It is pretty standard to have a headings font and contrast with a body font. But, a lot of times it is just a matter of the heading and body font being the same font, but having different weights. So, the body and heading seems like a pragmatic diction.

[pbking]

We originally did such a thing with Blockbase where a Header and Body font are declared. Each child was free to designate different font families to just those values and allow a user to change them via the Customizer. Patterns and themes were empowered to leverage those standardized values.

What we observed was that many themes leveraged only a single font. That meant a little extra configuration for them. Hardly any patterns or templates leveraged those values. When they did we found it was better to change configuration in theme.json instead. It was nearly always better to allow the underlying configuration flow through. And as to their re-use in theme.json configuration, we found that only two blocks ever leveraged the header value (wp-header, wp-page-title) and nothing the body.

We've found it more expressive, if perhaps a bit more verbose, to allow child themes and variations the ability to describe where the fonts go. So with v2 we transitioned any configuration from body/heading to individual block configuration settings.

The matter of those font values being unavailable should a user choose them and change themes; There's no guarantee that the theme they are switching to follows the same pattern. Better to try to express the configuration of fonts in a way that users aren't inclined to change individually but rather at a global level.

[colorful-tones]

It might help to guide this conversation if we were to refine the expectation of what fonts and how fonts should be used in this theme?

@beafialho @mikachan are the goals for TT3 to only leverage the following font families in all submitted style variations:

• DM Sans
• Source Serif Pro
• IBM Plex Mono, and
• system font families

[thelovekesh]

@mikachan My question is a little off-topic on the issue but is there any reason to use DM Sans font in the ttf format? I think woff or woff2 will provider a better font compression.

[mikachan]

Apologies, I've only just read this conversation. Thanks for the ping!

are the goals for TT3 to only leverage the following font families in all submitted style variations:

Yes, I believe this is the intention. Or rather, there should be a limited set of font families bundled with the theme, but the final set may change based on what people would prefer to use. For example, we may collectively decide to swap Source Serif Pro for a different font.

Considering we have a limited set of fonts to work with, I really like this idea:

TT3 theme - with 2-4 style variations, and
TT3 child theme - with a handful of community-contributed style variations

Especially in regards to creating a directory of many community-contributed style variations that are perhaps not bundled with the default theme, but offer a variation that is designed to work with TT3 easily and without any required customization.

[mikachan]

My question is a little off-topic on the issue but is there any reason to use DM Sans font in the ttf format? I think woff or woff2 will provider a better font compression.

No good reason other than these are the versions of the files used in TT2. Having them in woff or woff2 format sounds like a better plan!