[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