Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Webfonts API outputs only the first @font-face of a theme.json defined font-family in frontend #40453

Closed
jakobwiens7 opened this issue Apr 19, 2022 · 2 comments · Fixed by #40489
Labels
[Type] Bug An existing feature does not function as intended

Comments

@jakobwiens7
Copy link

Description

While working on a project, i noticed that my font styles were not displaying as they should (italic style was simulated and font weights other than regular weren't working at all).
I then realized, that apparently only the first @font-face declaration of a webfont is being output in frontend when you register them via theme.json.
It works as expected in the editor, where every style is being enqeued and therefore displayed properly.
I also was able to reproduce the issue on a fresh local WordPress installation with just the Gutenberg plugin and the TT2 theme.

What i expect:
Every @font-face declaration in a font-family is being registered and output (at least when they're used on the current page).

What actually happens:
Only the first @font-face in a font-family definition is being output (frontend only).

Step-by-step reproduction instructions

  1. Follow the testing instructions mentioned in Webfonts API #37140
    (or just define a fontFamily with more than one fontFace declaration in theme.json[settings][typography][fontFamilies])
  2. Inspect the html output inline style webfonts-inline-css

Screenshots, screen recording, code snippet

"fontFamilies": [
  {
	  "fontFamily": "-apple-system,BlinkMacSystemFont,\"Segoe UI\",Roboto,Oxygen-Sans,Ubuntu,Cantarell,\"Helvetica Neue\",sans-serif",
	  "name": "System Font",
	  "slug": "system-font"
  },
  {
	  "fontFamily": "\"Source Serif Pero\", serif",
	  "name": "Source Serif Pero",
	  "slug": "source-serif-pero",
	  "fontFace": [
		  {
			  "fontFamily": "Source Serif Pero",
			  "fontWeight": "200 900",
			  "fontStyle": "normal",
			  "fontStretch": "normal",
			  "src": [ "file:./assets/fonts/SourceSerif4Variable-Roman.ttf.woff2" ]
		  },
		  {
			  "fontFamily": "Source Serif Pero",
			  "fontWeight": "200 900",
			  "fontStyle": "italic",
			  "fontStretch": "normal",
			  "src": [ "file:./assets/fonts/SourceSerif4Variable-Italic.ttf.woff2" ]
		  }
	  ]
  }
],

The above theme.json[settings][typography][fontFamilies] definition outputs the following style in frontend:

image
(Notice the missing italic style @font-face declaration)

Environment info

  • WordPress v5.9.3, Gutenberg v13.0, Twenty Twenty-Two v1.1
  • Chrome, Firefox
  • Windows 10 Desktop

Please confirm that you have searched existing issues in the repo.

Yes

Please confirm that you have tested with all plugins deactivated except Gutenberg.

Yes

@bph bph added [Feature] Webfonts Needs Testing Needs further testing to be confirmed. [Type] Bug An existing feature does not function as intended labels Apr 19, 2022
@jakobwiens7
Copy link
Author

And i'm having even more trouble using wp_register_webfonts to add webfonts.
In frontend the inline style with the @font-face declarations is not being printed out at all - but again, in the editor this is working properly, as all font-faces seem to be enqeued and displayed.

I am really not sure what i could be missing here since i followed the testing instructions in #37140 very closely (including the suggestions mentioned in #37140 (review)).

@jakobwiens7 jakobwiens7 changed the title Webfonts API outputs only the first @font-face definition per font-family Webfonts API outputs only the first @font-face of a theme.json defined font-family in frontend Apr 20, 2022
@skorasaurus skorasaurus removed the Needs Testing Needs further testing to be confirmed. label Apr 20, 2022
@skorasaurus
Copy link
Member

PR for this at #40489

@skorasaurus skorasaurus added the [Status] In Progress Tracking issues with work in progress label Apr 20, 2022
@pbking pbking linked a pull request Apr 21, 2022 that will close this issue
@priethor priethor removed the [Status] In Progress Tracking issues with work in progress label May 22, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
[Type] Bug An existing feature does not function as intended
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants