Font Face: Get name from "fontFamily" setting, not "name". #54615

hellofromtonya · 2023-09-19T17:13:42Z

What?

Get the font-family name from the "fontFamily" field, instead of the"name" field.

Why?

To avoid a back-compatibility (BC) break for themes that do not have the "name" setting defined.

WP Core also does not require the "name" setting. Using it exclusively is a BC break in Core.

It's not clearly documented that the "name" setting is required. Thus, it's been optional.

How?

Use the font-family's fontFamily field instead of its name field.

As the fontFamily field could be a comma-separated list of font-families, it parses the list to extract the first entry, using the same approach in the Fonts API.

Why `fontFamily` setting?

WP_Theme_JSON schema requires the fontFamily setting in each of the typography.fontFamilies.

Testing Instructions

Use WordPress 6.3, not Coretrunk. (Why? trunk has Font Face in it, so the Font Face files in Gutenberg will not load into memory.)
Activate the Twenty-Twenty-Three (TT3) theme.
Open the TT3 theme.json file in your favorite editor and modify it as follows:
- Scroll to line 152 and delete the "name": "DM Sans", line.
- Save.
In your browser, open its dev tools and in the HTML inspector, search for and expand the wp-fonts-local style element.

Expected:

Without this PR fix, DM Sans should not be included in the @font-face styles ❌
With this PR fix, DM Sans should be included in the @font-face styles ✅

If the "name" setting does not exist, then get it from the "fontFamily" setting.

github-actions · 2023-09-19T17:15:23Z

This pull request has changed or added PHP files. Please confirm whether these changes need to be synced to WordPress Core, and therefore featured in the next release of WordPress.

If so, it is recommended to create a new Trac ticket and submit a pull request to the WordPress Core Github repository soon after this pull request is merged.

If you're unsure, you can always ask for help in the #core-editor channel in WordPress Slack.

Thank you! ❤️

View changed files

❔ lib/compat/wordpress-6.4/fonts/font-face/class-wp-font-face-resolver.php

To avoid reflection issues on different PHP versions and potential contributor confusion, merging the new tests into the existing test.

pbking · 2023-09-19T19:10:42Z

If the name has ' symbols those are included. We should also strip out any ' or "

matiasbenedetto · 2023-09-19T19:11:04Z

👋

I think we should not default to using the name of a font family as the default value for the CSS font faces printed into the site. If the name is not exactly the same as one of the values of fontFamily that breaks. Let's say that a theme adds a font family like this:

{
	"fontFace": [
		{
			"fontFamily": "Cardo",
			"fontStyle": "normal",
			"fontWeight": "700",
			"src": [
				"file:./assets/fonts/cardo_normal_700.woff2"
			]
		}
	],
	"fontFamily": "Cardo",
	"name": "Heading",
	"slug": "heading"
}

The font face css definition in this case is:

@font-face {
  font-family: Heading;
  font-style: normal;
  font-weight: 700;
  font-display: fallback;
  src: url("http://localhost/wp1/wp-content/themes/twentytwentyfour/assets/fonts/cardo_normal_700.woff2")
    format("woff2");
}

And the css preset is:

--wp--preset--font-family--heading: Cardo;

So, the font is not rendering as expected.

matiasbenedetto · 2023-09-19T19:19:23Z

I think the backup of using the first value of the family fontFamily property seems to be working better and seems much more difficult to break. But adds complexity that may be avoided. What do you think of using the font face fontFamily property to render the font face CSS definitions (@font-face ) ?

So following the previous example we could have something like the following:

theme.json font family definition

{
	"fontFace": [
		{
			"fontFamily": "Cardo",
			"fontStyle": "normal",
			"fontWeight": "700",
			"src": [
				"file:./assets/fonts/cardo_normal_700.woff2"
			]
		}
	],
	"fontFamily": "Cardo, system-ui",
	"name": "Heading",
	"slug": "heading"
}

Output css for font face

@font-face {
  font-family: Cardo;
  font-style: normal;
  font-weight: 700;
  font-display: fallback;
  src: url("http://localhost/wp1/wp-content/themes/twentytwentyfour/assets/fonts/cardo_normal_700.woff2")
    format("woff2");
}

CSS preset value:

--wp--preset--font-family--heading: Cardo;

pbking · 2023-09-19T19:26:05Z

What do you think of using the font face fontFamily property to render the font face CSS definitions (@font-face ) ?

That collection isn't required right? System fonts would not. However there will always be a "first item in the list" for fontFamily.

I think it would be great to use that value for the @font-face value though. There won't be one of those for system fonts anyway. It's just not the best backup for 'name' but perhaps the best source for @font-face.

pbking · 2023-09-19T19:28:25Z

Before this change the 'Name' rendered in the editor was derived some other way when the name: attribute was missing and the fontFamily was a list the whole list wasn't shown. With this change the whole value of fontFamily is displayed in the editor UI

hellofromtonya · 2023-09-19T19:43:56Z

I think the backup of using the first value of the family fontFamily property seems to be working better and seems much more difficult to break. But adds complexity that may be avoided. What do you think of using the font face fontFamily property to render the font face CSS definitions (@font-face ) ?

@matiasbenedetto Hmm what if the name is different from the fontFamily? Why would it be?

If the name exists, I think that's being used to populate the Typography pickers in the editors. Having a different name would be confusing to users. But an extender may have reasons to make the 2 setting values different.

So to protect the styles, I think you're right - it should use the required fontFamily and not the name setting.

matiasbenedetto · 2023-09-19T19:51:09Z

it should use the required fontFamily and not the name setting.

Yep, just to reiterate I would prefer to use the font face fontFamily property instead of the family fontFamily one. Both are required fields on theme.json schema, but I think it would be better to use the font face one because it shouldn't need extra processing (spliting by comma) and seems like a good place to indicate that parameter explicitly.

hellofromtonya · 2023-09-19T20:00:56Z

Before this change the 'Name' rendered in the editor was derived some other way when the name: attribute was missing and the fontFamily was a list the whole list wasn't shown. With this change the whole value of fontFamily is displayed in the editor UI

@pbking Font Face is read-only of Theme JSON. It's not involved in what gets populated in the typography pickers.

Testing it with only Core's trunk and with WP 6.3.1 (i.e. not with this PR or the Gutenberg plugin), I see the same problem:

You found a bug. Want to open a new issue for it?

hellofromtonya · 2023-09-19T20:02:16Z

Yep, just to reiterate I would prefer to use the font face fontFamily property instead of the family fontFamily one. Both are required fields on theme.json schema, but I think it would be better to use the font face one because it shouldn't need extra processing (spliting by comma) and seems like a good place to indicate that parameter explicitly.

@matiasbenedetto What happens though if an extender has copied and pasted the family fontFamily value? It could also have a comma-separated list of font families.

hellofromtonya · 2023-09-19T20:05:55Z

That collection isn't required right? System fonts would not. However there will always be a "first item in the list" for fontFamily.

@pbking The System fonts though do not have fontFace variations, right? The first check (before getting the font-family name) skips the font if there's no fontFace declared.

Do not the "name" settting. Instead only use the required "fontFamily" setting.

matiasbenedetto · 2023-09-19T20:20:08Z

@matiasbenedetto What happens though if an extender has copied and pasted the family fontFamily value? It could also have a comma-separated list of font families.

It seems less likely, but in that case, we can maintain the coma-splitting safety. Apart from that, It would be nice to document each field properly so extenders know what is expected in each field.

hellofromtonya · 2023-09-19T20:27:16Z

It seems less likely, but in that case, we can maintain the coma-splitting safety.

I think the comma-splitting is needed, just in case.

Apart from that, It would be nice to document each field properly so extenders know what is expected in each field.

Do you mean each field in the theme.json file?

matiasbenedetto · 2023-09-19T20:31:44Z

Do you mean each field in the theme.json file?

Yes, but that's not part of the scope of this PR. Just a nice thing to have in the future.

Co-authored-by: Brian Alexander <824344+ironprogrammer@users.noreply.github.com>

…he former is not being used Co-authored-by: Brian Alexander <824344+ironprogrammer@users.noreply.github.com>

Co-authored-by: Brian Alexander <824344+ironprogrammer@users.noreply.github.com>

github-actions · 2023-09-20T20:21:51Z

Flaky tests detected in 014b4e3.
Some tests passed with failed attempts. The failures may not be related to this commit but are still reported for visibility. See the documentation for more information.

🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/6253339061
📝 Reported issues:

[Flaky Test] should make the modal content focusable when it is scrollable #48067 in /test/e2e/specs/editor/various/a11y.spec.js
[Flaky Test] should partially select with shift + click (@webkit) #53524 in /test/e2e/specs/editor/various/multi-block-selection.spec.js

ironprogrammer

Refreshed with trunk and LGTM 👍🏻

Because `WP_Font_Face_Resolver` already exists in Core release code, this update cannot be tested in CI without migrating the code into a temporary `_Gutenberg` resolver, which will complicate syncing back to Core. Test will be added to a follow-up PR, to merge once this update is synced to Core. Note that this test does succeed when run locally against WP `trunk` (currently 6.4-alpha).

Iff the "name" setting does not exist (as it's not required by the schema or documentation), get the font-family name from the required "fontFamily" setting, i.e. within each `typography.fontFamilies`.

mikachan · 2023-09-25T08:44:24Z

I just cherry-picked this PR to the release/16.7 branch to get it included in the next release: 5cde445

hellofromtonya · 2023-09-25T15:58:02Z

PR 5298 WordPress/wordpress-develop#5298 ports the Resolver changes and tests to Core. Once committed, the tests can be (re) added into the Gutenberg repo for the CI jobs running against Core's trunk (those that were previously failing).

Instead of getting the name from the optional `'name'` field, the font-family name now comes from the required `'fontFamily'` field. This change fixes a back-compat (BC) break in how the font-family name is pulled from the incoming font data in the `WP_Font_Face_Resolver`. Why? WP Core does not require the `'name'` field in theme.json. For themes that do not declare it, that set of font variations is ignored, thus causing a BC break from how the stopgap code worked (see [53282]). However, `WP_Theme_JSON` schema does require the `fontFamily` field in each of the `typography.fontFamilies`. == Other details: Includes a parser to extract the first entry when a `fontFamily` field has a comma-separated list of font-families, e.g. `Inter, sans-serif`. References: * Merge from Gutenberg's PR WordPress/gutenberg#54615. Follow-up to [56500], [53282]. Props ironprogrammer, hellofromTonya, mmaattiiaass, pbking. Fixes #59165. git-svn-id: https://develop.svn.wordpress.org/trunk@56688 602fd350-edb4-49c9-b593-d223f7449a82

Instead of getting the name from the optional `'name'` field, the font-family name now comes from the required `'fontFamily'` field. This change fixes a back-compat (BC) break in how the font-family name is pulled from the incoming font data in the `WP_Font_Face_Resolver`. Why? WP Core does not require the `'name'` field in theme.json. For themes that do not declare it, that set of font variations is ignored, thus causing a BC break from how the stopgap code worked (see [53282]). However, `WP_Theme_JSON` schema does require the `fontFamily` field in each of the `typography.fontFamilies`. == Other details: Includes a parser to extract the first entry when a `fontFamily` field has a comma-separated list of font-families, e.g. `Inter, sans-serif`. References: * Merge from Gutenberg's PR WordPress/gutenberg#54615. Follow-up to [56500], [53282]. Props ironprogrammer, hellofromTonya, mmaattiiaass, pbking. Fixes #59165. Built from https://develop.svn.wordpress.org/trunk@56688 git-svn-id: https://core.svn.wordpress.org/trunk@56200 1a063a9b-81f0-0310-95a4-ce76da25c4cd

Instead of getting the name from the optional `'name'` field, the font-family name now comes from the required `'fontFamily'` field. This change fixes a back-compat (BC) break in how the font-family name is pulled from the incoming font data in the `WP_Font_Face_Resolver`. Why? WP Core does not require the `'name'` field in theme.json. For themes that do not declare it, that set of font variations is ignored, thus causing a BC break from how the stopgap code worked (see [53282]). However, `WP_Theme_JSON` schema does require the `fontFamily` field in each of the `typography.fontFamilies`. == Other details: Includes a parser to extract the first entry when a `fontFamily` field has a comma-separated list of font-families, e.g. `Inter, sans-serif`. References: * Merge from Gutenberg's PR WordPress/gutenberg#54615. Follow-up to [56500], [53282]. Props ironprogrammer, hellofromTonya, mmaattiiaass, pbking. Fixes #59165. Built from https://develop.svn.wordpress.org/trunk@56688 git-svn-id: http://core.svn.wordpress.org/trunk@56200 1a063a9b-81f0-0310-95a4-ce76da25c4cd

Instead of getting the name from the optional `'name'` field, the font-family name now comes from the required `'fontFamily'` field. This change fixes a back-compat (BC) break in how the font-family name is pulled from the incoming font data in the `WP_Font_Face_Resolver`. Why? WP Core does not require the `'name'` field in theme.json. For themes that do not declare it, that set of font variations is ignored, thus causing a BC break from how the stopgap code worked (see [53282]). However, `WP_Theme_JSON` schema does require the `fontFamily` field in each of the `typography.fontFamilies`. == Other details: Includes a parser to extract the first entry when a `fontFamily` field has a comma-separated list of font-families, e.g. `Inter, sans-serif`. References: * Merge from Gutenberg's PR WordPress/gutenberg#54615. Follow-up to [56500], [53282]. Props ironprogrammer, hellofromTonya, mmaattiiaass, pbking. Fixes #59165. git-svn-id: https://develop.svn.wordpress.org/trunk@56688 602fd350-edb4-49c9-b593-d223f7449a82

bph · 2023-10-04T09:54:46Z

Solves:

'name' attribute is now required on Font Face definitions (breaking many existing themes) #54605

Gets name from fontFamily as fallback check.

5689b53

If the "name" setting does not exist, then get it from the "fontFamily" setting.

hellofromtonya added [Type] Bug An existing feature does not function as intended Needs PHP backport Needs PHP backport to Core [Feature] Typography Font and typography-related issues and PRs labels Sep 19, 2023

hellofromtonya self-assigned this Sep 19, 2023

hellofromtonya requested review from ironprogrammer and matiasbenedetto September 19, 2023 17:22

hellofromtonya marked this pull request as ready for review September 19, 2023 17:22

hellofromtonya requested a review from spacedmonkey as a code owner September 19, 2023 17:22

hellofromtonya mentioned this pull request Sep 19, 2023

Font Face: avoid using non required property as index and use right property to render font face #54610

Closed

hellofromtonya removed the request for review from spacedmonkey September 19, 2023 17:36

hellofromtonya enabled auto-merge (squash) September 19, 2023 18:47

Move tests into existing test.

370caf0

To avoid reflection issues on different PHP versions and potential contributor confusion, merging the new tests into the existing test.

hellofromtonya force-pushed the fix/font-face/backup-font-family-name-check branch from 533ae9d to 370caf0 Compare September 19, 2023 18:51

Do not use "name".

1c1b96e

Do not the "name" settting. Instead only use the required "fontFamily" setting.

hellofromtonya changed the title ~~Font Face: Get name from "fontFamily" setting if "name" setting does not exist.~~ Font Face: Get name from "fontFamily" setting, not "name". Sep 19, 2023

matiasbenedetto and others added 4 commits September 20, 2023 16:37

trim quotes on font family name

8483b7f

Co-authored-by: Brian Alexander <824344+ironprogrammer@users.noreply.github.com>

making sure the name value differs from fontFamily to validate that t…

e0f88c0

…he former is not being used Co-authored-by: Brian Alexander <824344+ironprogrammer@users.noreply.github.com>

validate trimming changes

60a5a50

Co-authored-by: Brian Alexander <824344+ironprogrammer@users.noreply.github.com>

Merge branch 'trunk' into fix/font-face/backup-font-family-name-check

014b4e3

Merge branch 'trunk' into fix/font-face/backup-font-family-name-check

084e83d

ironprogrammer approved these changes Sep 22, 2023

View reviewed changes

hellofromtonya merged commit 4aa0382 into trunk Sep 22, 2023
49 checks passed

hellofromtonya deleted the fix/font-face/backup-font-family-name-check branch September 22, 2023 23:08

github-actions bot added this to the Gutenberg 16.8 milestone Sep 22, 2023

mikachan added the Backport to Gutenberg RC Pull request that needs to be backported to a Gutenberg release candidate (RC) label Sep 22, 2023

mikachan modified the milestones: Gutenberg 16.8, Gutenberg 16.7 Sep 22, 2023

mikachan removed the Backport to Gutenberg RC Pull request that needs to be backported to a Gutenberg release candidate (RC) label Sep 25, 2023

SiobhyB mentioned this pull request Sep 25, 2023

Plugin: Synchronize PHP changes for WordPress 6.4 release #54177

Closed

86 tasks

hellofromtonya mentioned this pull request Sep 25, 2023

Font Face: Fix getting the font-family name WordPress/wordpress-develop#5298

Closed

hellofromtonya removed the Needs PHP backport Needs PHP backport to Core label Sep 25, 2023

bph mentioned this pull request Oct 4, 2023

'name' attribute is now required on Font Face definitions (breaking many existing themes) #54605

Closed

This was referenced Dec 19, 2023

Font Face: Inconsistency between font-family value in theme.json preset and font-family value in generated @font-face. #57207

Open

Font Library: WordPress 6.5 Required Tasks #55277

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Font Face: Get name from "fontFamily" setting, not "name". #54615

Font Face: Get name from "fontFamily" setting, not "name". #54615

hellofromtonya commented Sep 19, 2023 •

edited

Loading

github-actions bot commented Sep 19, 2023 •

edited

Loading

pbking commented Sep 19, 2023 •

edited

Loading

matiasbenedetto commented Sep 19, 2023 •

edited

Loading

matiasbenedetto commented Sep 19, 2023

pbking commented Sep 19, 2023

pbking commented Sep 19, 2023 •

edited

Loading

hellofromtonya commented Sep 19, 2023

matiasbenedetto commented Sep 19, 2023

hellofromtonya commented Sep 19, 2023

hellofromtonya commented Sep 19, 2023 •

edited

Loading

hellofromtonya commented Sep 19, 2023

matiasbenedetto commented Sep 19, 2023

hellofromtonya commented Sep 19, 2023 •

edited

Loading

matiasbenedetto commented Sep 19, 2023

github-actions bot commented Sep 20, 2023

ironprogrammer left a comment

mikachan commented Sep 25, 2023

hellofromtonya commented Sep 25, 2023

bph commented Oct 4, 2023 •

edited

Loading

Font Face: Get name from "fontFamily" setting, not "name". #54615

Font Face: Get name from "fontFamily" setting, not "name". #54615

Conversation

hellofromtonya commented Sep 19, 2023 • edited Loading

What?

Why?

How?

Why fontFamily setting?

Testing Instructions

github-actions bot commented Sep 19, 2023 • edited Loading

pbking commented Sep 19, 2023 • edited Loading

matiasbenedetto commented Sep 19, 2023 • edited Loading

matiasbenedetto commented Sep 19, 2023

pbking commented Sep 19, 2023

pbking commented Sep 19, 2023 • edited Loading

hellofromtonya commented Sep 19, 2023

matiasbenedetto commented Sep 19, 2023

hellofromtonya commented Sep 19, 2023

hellofromtonya commented Sep 19, 2023 • edited Loading

hellofromtonya commented Sep 19, 2023

matiasbenedetto commented Sep 19, 2023

hellofromtonya commented Sep 19, 2023 • edited Loading

matiasbenedetto commented Sep 19, 2023

github-actions bot commented Sep 20, 2023

ironprogrammer left a comment

Choose a reason for hiding this comment

mikachan commented Sep 25, 2023

hellofromtonya commented Sep 25, 2023

bph commented Oct 4, 2023 • edited Loading

hellofromtonya commented Sep 19, 2023 •

edited

Loading

Why `fontFamily` setting?

github-actions bot commented Sep 19, 2023 •

edited

Loading

pbking commented Sep 19, 2023 •

edited

Loading

matiasbenedetto commented Sep 19, 2023 •

edited

Loading

pbking commented Sep 19, 2023 •

edited

Loading

hellofromtonya commented Sep 19, 2023 •

edited

Loading

hellofromtonya commented Sep 19, 2023 •

edited

Loading

bph commented Oct 4, 2023 •

edited

Loading