WordPress.org

Make WordPress Core

Opened 9 months ago

Last modified 5 weeks ago

#46169 new enhancement

Use system fonts for the block editor

Reported by: garrett-eclipse Owned by:
Milestone: Awaiting Review Priority: normal
Severity: normal Version: 5.0
Component: Editor Keywords: needs-design-feedback 2nd-opinion dev-feedback
Focuses: performance, privacy Cc:
PR Number:

Description

Following from a discussion in #core-privacy I'm opening this to move on the Google Fonts issue with Gutenberg.
Discussion - https://wordpress.slack.com/archives/C9695RJBW/p1549043771637800

There's two main concerns;

  1. From a privacy standpoint Google Fonts tracks users potentially collecting PII
  2. From a performance standpoint the assets should be served locally to take advantage of modern font-loading optimization, etc. The cross-domain request slows down the site even with pre-fetching.

This was originally raised in Gutenberg Github and closed as it's now a core issue;
https://github.com/WordPress/gutenberg/issues/11648

This was perviously done in 4.6 to remove Open Sans as done here;
https://core.trac.wordpress.org/ticket/36753

Thank you

Change History (14)

#1 @garrett-eclipse
9 months ago

Specifically, this is for the replacement of Noto Serif the Google Font used by the block editor.

Core reference - https://github.com/WordPress/WordPress/blob/3c7a623f85f4648eded5cbcf340ccb5c9cc3b2fb/wp-includes/script-loader.php#L1929-L1938

#2 @joyously
9 months ago

This would be better for when the styles are being overridden also.

This ticket was mentioned in Slack in #core-privacy by garrett-eclipse. View the logs.


9 months ago

#4 in reply to: ↑ description @pento
9 months ago

  • Keywords needs-design added

Replying to garrett-eclipse:

  1. From a privacy standpoint Google Fonts tracks users potentially collecting PII

Is there a reference for this? Reading through this discussion and the related FAQ, it seems like Google logs minimal data from Google Fonts requests.

  1. From a performance standpoint the assets should be served locally to take advantage of modern font-loading optimization, etc. The cross-domain request slows down the site even with pre-fetching.

Google Fonts is pretty fast. The first request to load the block editor from my site takes ~8s, of which 80ms is Noto Serif. Subsequent loads are 4s for the page load, and 0ms for Noto Serif, thanks to caching. This seems like a premature optimisation.

I'll defer to the design team as to whether system fonts are a better (or at least equivalent) writing experience compared to Noto Serif.

#5 @aristath
9 months ago

Is there a reference for this? Reading through this discussion and the related FAQ, it seems like Google logs minimal data from Google Fonts requests.

Google claims it logs minimal data, however there is no mention whatsoever of what data gets logged, for how long the logs remain and what kind of processing google then does on the logged data. Google's FAQ only states that "The Google Fonts API is designed to limit the collection, storage, and use of end-user data to what is needed to serve fonts efficiently" without providing any specifics.
The vagueness of their docs, the lack of information and specificity is what makes them a serious GDPR concern.

Google Fonts is pretty fast.

In general yes, they're pretty fast. But that's only because your connection and mine are fast. But a few days ago when there were heavy rains in my area for example and connection speeds were suffering, gfonts were a constant pain. We should not assume that everyone has a decent network or that they have the luxury of an 80ms request for webfonts.

I'll defer to the design team as to whether system fonts are a better (or at least equivalent) writing experience compared to Noto Serif.

Note Serif is a better experience, there's no doubt about that. It's a beautiful font. But it's not what themes use on the frontend so the editor should not assume anything and should not use an opinionated font. If a theme uses Noto Serif then it should enqueue it on its own in the editor.

#6 @joyously
9 months ago

Note Serif is a better experience, there's no doubt about that. It's a beautiful font.

Only in certain languages. If you use system fonts, there is no lag, no privacy concern, and the user gets the font they've already chosen as very readable. If this is just for the editor chrome, it's the best choice to use system fonts (like sans-serif). If it's for the content, the editor should not be specifying anything at all.

This ticket was mentioned in Slack in #core-privacy by dejliglama. View the logs.


8 months ago

This ticket was mentioned in Slack in #core-privacy by postphotos. View the logs.


8 months ago

#9 @garrett-eclipse
8 months ago

Thanks @pento @joyously & @aristath for the input.

Google Fonts seems to be a recurring discussion in the #core-privacy channel as well as the privacy community at large as Google is so ambiguous with the disclosure of data usage that they become a concern. At minimum Google collects your IP address and the website/page source from which the call was made this assist them in understanding your browsing habits and potentially enables them to serve more targetted ads towards you. Google may not be doing this right now but their privacy policies enable them if they would like. Google Fonts along with all Google APIs are bound by the generic API terms of service which includes this clause;
"For the sole purpose of enabling Google to provide, secure, and improve the APIs (and the related service(s)) and only in accordance with the applicable Google privacy policies, you give Google a perpetual, irrevocable, worldwide, sublicensable, royalty-free, and non-exclusive license to Use content submitted, posted, or displayed to or from the APIs through your API Client. "Use" means use, host, store, modify, communicate, and publish."
Reference - https://developers.google.com/terms/
Google Privacy Policy (https://policies.google.com/privacy) enables it to collect large amounts of user data through its services including log data (browser version) and location data (IP Address). Sites that use Google Fonts are feeding data back to Google. It's possible that Google doesn't actively collect or use the data from Google Fonts but there's no assurance or disclosure which prompts those who are privacy-conscious to seek alternatives.

That being said there's no definitive source on how much data Google Fonts feeds to Google or how they utilize that data. But with the Core Privacy team trying to move WordPress to a Privacy by Design methodology removing the possibility of undisclosed data collection is a huge benefit to the community.

To my understanding though WordPress has been moving away from the use of CDN's and external resources and another approach could very well be bundling the Noto Serif font directly into WP which would allay any privacy and performance concerns while still providing the same experience.

Another point on avoiding external resources is local development while offline is hindered by the use of external resources. I myself have 1-2 hour bus commute both ways to/from work and I often spin up WP instances on my machine with no internet connection. Avoiding external resources assists those with minimal or no internet connection.

In my opinion I'd be happy with either switching out the gFont for a system font or bundling it with WordPress to remove the external call and potential data leakage.

All the best

This ticket was mentioned in Slack in #core-editor by youknowriad. View the logs.


7 months ago

#11 @garrett-eclipse
6 months ago

  • Keywords needs-design-feedback 2nd-opinion dev-feedback added; needs-patch removed

Hello All,

I just wanted to update the thread with some discussion posted via make/core that is applicable to the discussion here and provides potential forward direction. I hope those mentioned in the quoted text don't mind the ping, I mostly want to direct further discussion via this ticket in order to have it be a central point for this request. As well I didn't want to quote without indicating such to the original commenters.

The following thread comes from comments on these office hours minutes;
https://make.wordpress.org/core/2019/02/20/core-privacy-office-hours-minutes-13-february-2019/

Tom J Nowell (@tjnowell) 5:14 am on February 20, 2019

a proof of concept patch to add a customizer option to disable Google Fonts for the older (pre-Twenty Nineteen) default themes.

Can we not just bundle the fonts? That way no user opt in or out is necessary. Additionally, there’s no mention of this in either of the quoted tickets

Also, are we disregarding the precedent set when the Google Font was removed from MP6 in WP Admin? /cc @pento It seems to me that the TLDR is that a mistake was made adding Noto Serif via Google Fonts probably due to a lack of awareness. Rather than admit it, it’s been swept under the rug so that the decision can be made a second time to save face, or at least that’s how it looks. Honestly it isn’t such a big deal, I suggest sticking to the original decision

###REPLY###
Gary Pendergast (@pento) 8:24 pm on February 20, 2019

Open Sans was removed from wp-admin in WordPress 4.6, several years after the MP6 redesign released in WordPress 3.8. It was removed because system fonts had reached a point where the admin could be rendered in a consistent manner with good fonts across all platforms (#36753).

I’d like to see more research into the font bundling option, as some translations will use the localised version of the relevant font (for example, Japanese uses Noto Serif JP), while others will choose to use system fonts where no good equivalent font exists (eg, Hebrew). This can vary by font, too, as Hebrew does use Inconsolata loaded from Google Fonts in Twenty Fifteen.

There’s some relevant discussion on GB2798: this was a deliberate decision to use Noto Serif over system fonts, the folks making that decision were clearly aware of the tradeoffs.

There are multiple criteria that need to be met for changes to happen here:

A font change would need to be approved by a Gutenberg design lead. @karmatosed, @joen, or @mapk could provide more insight here.
Bundling fonts would need to not increase the wordpress.zip file size significantly.
Bundled fonts would need to be released under a GPL2-compatible license.
Bundling fonts would also need the appropriate infrastructure in place to switch font by language.
I’m fine with this change happening, but folks working on it should be aware that there are significant hurdles to overcome in order to avoid it creating a poor user experience.

###REPLY###
Joen Asmussen (@joen) 11:41 pm on February 20, 2019

We certainly don’t want lumpy rugs!

I can speak to this, as I was part of the decision-making process. As is hopefully clear from the discussion on the ticket, no malice was intended in linking to Google’s servers, and for the past two years of the font being in place the major concerns around the font choice were related to localization challenges and performance.

As you bring it up, I do recall Open Sans being removed for privacy reasons. It’s unfortunate we forgot to bring that up during the discussion, it should have been. I recall the time of discussion being an incredibly challenging phase of the project, for everyone involved, and although in hindsight this should’ve had more thought, so many gears were in motion at the time, that it was perhaps easy for us to forget, or postpone and then forget. I hope that as we try to attract a new generation of WordPress contributors, we can surface past decisions like these in a way that empowers and encourages, as opposed to discourage.

In addition to what is mentioned on the thread, one of the reasons Noto Serif stayed in place (aside from being more pleasant to read than Georgia) was to imply that the block editor is more than just a generic post editor; that via editor styles you can make it look the same as the theme itself. Georgia, and to a vastly greater extent Times New Roman, imply “generic” in a way that if you see Times New Roman on a website you might think the CSS is still loading. Simply put, the goal of Noto was to suggest that there are styling opportunities here.

This hasn’t worked as well as we intended. In actual practice, and by virtue of being a theme that actually styles the editor, Twenty Nineteen has done far more to get that point across than the vanilla editor style ever could.

In that vein, and as is also hopefully clear from that discussion linked, removing Noto Serif from the editor, or bundling it, is likely not going to meet blocking pushback, even if we might want to pour one out for it.

I greatly appreciate this has been discussed in detail, thank you.

As Gary mentioned, "I’m fine with this change happening, but folks working on it should be aware that there are significant hurdles to overcome in order to avoid it creating a poor user experience.", I've added a needs-design-feedback to start the discussion on this as the decision to utilize bundled fonts or system fonts is more ux/ui related since both options satisfy the privacy/performance concerns.

I'm also adding the 2nd-opinion and dev-feedback to expand the discussion but wanted to requote Gary as 'A font change would need to be approved by a Gutenberg design lead.'

Once a final decision is made this can be introduced to Gutenberg first as that would then end up in the corresponding Core release slightly later.
There's an existing ticket on Gutenberg that can be reopened to continue the initial work there;
https://github.com/WordPress/gutenberg/issues/11648

P.S. For now I've dropped the needs-patch as a decision is first required for the patch forward, and the actual implementation would more likely be done via GutenGitHub.

#12 @karmatosed
5 months ago

  • Keywords needs-design removed

This ticket was mentioned in Slack in #core-privacy by audrasjb. View the logs.


3 months ago

This ticket was mentioned in Slack in #core-themes by garrett-eclipse. View the logs.


5 weeks ago

Note: See TracTickets for help on using tickets.