Webfonts: register and enqueue fonts by font-family

[zaguiini]

What?

Part of #39332.

Why?

It's an attempt to make the webfonts API more flexible and save transferred data. We're now registering font families (individual font faces grouped by font-family) and enqueueing them as needed.

1. We more closely match the behavior of wp scripts and styles and accommodate functionality that WordPress developers are already familiar with.
2. We allow API consumers more flexibility in how and when they enqueue webfonts, rather than forcing them to enqueue all fonts indiscriminately.

How?

We're creating a hash of the font-family attribute and grouping registered font faces to their respective font families;

We then introduce enqueueing and do not add registered font-families to the output by default -- they must be explicitly added through enqueueing. All fonts are enqueued when opening the editor so fonts picked when making changes show up correctly.

Webfonts should be enqueued after the after_setup_theme hook runs because that's where registration happens. So we should recommend hooking into init or wp_loaded to enqueue fonts since it's guaranteed to be registered at the time that these hooks are run.

Testing a webfont loaded via theme.json:

Using the Bennett theme as an example, we edit its theme.json file and replace fontFamilies with the following:

"fontFamilies": [
    {
        "fontFamily": "Roboto",
        "name": "Roboto",
        "slug": "roboto",
        "fontFace": [
            {
                "fontFamily": "Roboto",
                "fontWeight": "900",
                "fontStyle": "normal",
                "fontStretch": "normal",
                "src": [ "file:./assets/fonts/Roboto-Regular.ttf" ]
            },
        ]
    }
],

Then, we create a functions.php in the bennett theme directory and add the following:

<?php

add_action( 'init', function() {
	wp_enqueue_webfont( 'Roboto' );
} );

Testing a webfont programmatically through PHP:

Next, to test the PHP registration using the wp_register_webfont function, in functions.php add the following:

add_action( 'after_setup_theme', function() {
	wp_register_webfont(
		array(
			'font-family'  => 'Roboto',
			'font-style'   => 'normal',
			'font-stretch' => 'normal',
			"font-weight" => "900",
			'src'          => get_theme_file_uri( '/assets/fonts/Roboto-Regular.ttf' ),
		)
	);
} );

add_action( 'wp_loaded', function() {
	wp_enqueue_webfont( 'Roboto' );
} );

Refresh the page and Roboto should be there. You can try adding another font of the same family in italic (font-style: italic) and changing the src. It should load both fonts.

When you remove wp_enqueue_webfont, Roboto should not be loaded anymore.

[zaguiini]

@hellofromtonya this is ready for review and adapted to your comments.

@aristath please take a look when possible 🙏

[creativecoder]

The overall approach is looking good and makes sense to me.

I think this is best reviewed in tandem with #39593, as the first real test is if it helps us remove unused font-face declarations to avoid unnecessarily bloating the html.

[hellofromtonya]

Rebased against latest trunk to resolve merge conflicts.

[hellofromtonya]

Scope of this PR - LGTM 👍

Other changes (such as tests, wiring theme.json enqueue, etc.) will be done in other PR(s).

[scruffian]

This file no longer seems to be loaded at all? I'd like to modify get_theme_data but I'm not sure how now...

[zaguiini]

Sorry @scruffian, what do you mean? It is listed in load.php: https://github.com/WordPress/gutenberg/blob/trunk/lib/load.php#L111.

[scruffian]

Sorry, looks like I was stuck in a bad merge state...

[bradhogan]

Is this now the way fonts should be loaded into a block theme? Any official documentation on this?

[zaguiini]

Hey @bradley2083,

Please read #39332 (comment).

[bradhogan]

@zaguiini Thanks for sharing that. So I'm still not 100% clear but sounds like we still need to use font-face declarations for the time being?

[zaguiini]

Sorry, @bradley2083.

We now have separated registration and enqueueing of fonts, just like we have with scripts and styles.

#39988 will enqueue the fonts listed in theme.json, even if they're registered programmatically (i.e. through the wp_register_webfont method).

After that, we'll work on #40363, so we can enqueue automatically the fonts picked in global styles.

So no, you won't need to use font-face declarations. The Webfonts API should be sufficient. Right now, you can use it to register and enqueue webfonts through the API.

When #39988 gets merged, you can use solely theme.json to register and enqueue fonts. Note that the picker in global styles won't work for externally/programmatically registered webfonts, only for the fonts explicitly listed in theme.json.

This problem will be addressed in #40363, so externally registered webfonts will be considered when enqueueing fonts to the front-end.

[bradhogan]

Ok got it. Thanks @zaguiini I'll start to play around with using wp_register_webfont I assume this is too early to have any documentation / examples for this stuff atm?

[zaguiini]

Yeah, right, @bradley2083. It's not going to be included in 6.0, so too early. But the methods in webfonts.php do have some documentation. It should be straightforward to understand what's going on.

[gigitux]

We noticed that with the new Gutenberg versions (from 13.0) the Global Styles for WC Blocks plugin doesn’t apply anymore.

It seems that the problem is caused by this PR, in particular, this this change.

I don't have a lot of context on this part of the code. Could you take a look? Thanks!

cc @zaguiini @hellofromtonya