[wp-trac] [WordPress Trac] #46169: Use system fonts for the block editor

WordPress Trac noreply at wordpress.org
Sat Apr 13 18:02:31 UTC 2019


#46169: Use system fonts for the block editor
-------------------------------------------------+-------------------------
 Reporter:  garrett-eclipse                      |       Owner:  (none)
     Type:  enhancement                          |      Status:  new
 Priority:  normal                               |   Milestone:  Awaiting
                                                 |  Review
Component:  Editor                               |     Version:  5.0
 Severity:  normal                               |  Resolution:
 Keywords:  needs-design needs-design-feedback   |     Focuses:
  2nd-opinion dev-feedback                       |  performance, privacy
-------------------------------------------------+-------------------------
Changes (by garrett-eclipse):

 * keywords:  needs-patch needs-design => needs-design needs-design-feedback
     2nd-opinion dev-feedback


Comment:

 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) [https://make.wordpress.org/core/2019/02/20/core-
 privacy-office-hours-minutes-13-february-2019/#comment-35412 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) [https://make.wordpress.org/core/2019/02/20/core-
 privacy-office-hours-minutes-13-february-2019/#comment-35425 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) [https://make.wordpress.org/core/2019/02/20/core-
 privacy-office-hours-minutes-13-february-2019/#comment-35427 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.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/46169#comment:11>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform


More information about the wp-trac mailing list