Hi @Luehrsen! 👋

Thank you for your contribution to WordPress! 💖

It looks like this is your first pull request to wordpress-develop. Here are a few things to be aware of that may help you out!

No one monitors this repository for new pull requests. Pull requests must be attached to a Trac ticket to be considered for inclusion in WordPress Core. To attach a pull request to a Trac ticket, please include the ticket's full URL in your pull request description.

Pull requests are never merged on GitHub. The WordPress codebase continues to be managed through the SVN repository that this GitHub repository mirrors. Please feel free to open pull requests to work on any contribution you are making.

More information about how GitHub pull requests can be used to contribute to WordPress can be found in this blog post.

Please include automated tests. Including tests in your pull request is one way to help your patch be considered faster. To learn about WordPress' test suites, visit the Automated Testing page in the handbook.

If you have not had a chance, please review the Contribute with Code page in the WordPress Core Handbook.

The Developer Hub also documents the various coding standards that are followed:

• PHP Coding Standards
• CSS Coding Standards
• HTML Coding Standards
• JavaScript Coding Standards
• Accessibility Coding Standards
• Inline Documentation Standards

Thank you,
The WordPress Project

The new @font-face rules use local('') in the src: declarations.

On the github repository for the Google Webfonts Helper there is an open issue about problems arising from using such declarations.
There is another open issue about the same type of declaration where I commented having another type of problem myself. I know I should have opened a separate ticket for my issue, but I realized that the project didn't seem to be mantained anymore (last code change is 5 years old), so I disited.

To avoid these problems, I would suggest to either use the "smiley" hack as mentioned here or drop the local('') part altogether.

To avoid these problems, I would suggest to either use the "smiley" hack as mentioned here or drop the local('') part altogether.

I think dropping local is the way to go.

I see this PR includes the font files in the repo, but installing them via NPM is also an option: https://fontsource.org/

I see this PR includes the font files in the repo, but installing them via NPM is also an option: https://fontsource.org/

This is how I would do it today. But I think the overhead in terms of packages and build tools is a little too much for the scope of what we want to achieve here. I don't think introducing a new package and build process for a legacy polyfill is wise here.

We can always go back and optimise if we wish to do that.

I think dropping local is the way to go.

Why not using the real local name local('Libre Franklin')? On my Manjaro laptop I have the Google Fonts package installed and load pretty much any Goole Web Font locally. Some operating systems have other local fonts installed by default.

Why not using the real local name local('Libre Franklin')? On my Manjaro laptop I have the Google Fonts package installed and load pretty much any Goole Web Font locally. Some operating systems have other local fonts installed by default.

Apparently there were cases with colliding font names. Originally Google Fonts used to add the local("Font Name") delarations but eventually removed them except for specific cases.

Another possible reason is that there is no control over which version of the font is loaded from the user's computer. The user could have a version with a limited character set or even incomplete variations installed.

Based on a discussion with @2ndkauboy I've rewritten the implementation and added the unicode-range selector. (#2823 (comment))

The downside is, that the font.css is really complex now and we have a lot of files. But the upside is, that character subsets get automatically loaded when needed.

I've rewritten the implementation and added the unicode-range selector.

That seems like a great solution!

I believe locally hosted fonts are the best way forward, but this is really interesting:

https://twitter.com/dimensionmedia/status/1538912055381463041

IMHO not without asking for consent first.

I think in terms of GDPR compliance it is OK without consent, as no personal data is sent to any non-EU entity.

But still I think for the default themes we should really go with local fonts.