Since 2013, WordPress has used Open Sans as the default font for the admin panel. For a number of years, Open Sans has been around, and considering the fact that Open Sans in itself is a really popular and pretty good-looking font, it has become a staple feature in the WordPress admin panel.
However, all of that is expected to change pretty soon. The upcoming version, WordPress 4.6, is planning to ditch Open Sans in favor of system fonts in the admin panel.
Here is what WordPress lead developer, Helen Hou-Sandi, stated in her commit message:
‚ÄúRejoice, for your admins will feel more native to your surrounding computing environment and likely load faster, especially when offline, as they no longer have to talk to The Google Overlord.
At the time of introduction in 3.8, there were not good system fonts common to all platforms at the time. In the years since, Windows, Android, OS X, iOS, Firefox OS, and various flavors of Linux have all gotten their own (good) system UI fonts.
There will definitely be visual bugs, mainly around alignment and spacing; these should be documented and reported on the ticket and fixed more atomically so that our current and future selves have a better understanding of what happened and why.
The style remains registered, as it is almost certainly in use by themes and plugins.‚ÄĚ
This is clearly not a big move in terms of features, but surely a very important because it will affect the look and feel of the admin panel. For years, we have come to expect Open Sans in the admin panel, and a new font (even if it is the system font) will surely take a lot of getting used to.
The roots of this idea can be traced back to the Font Natively feature that, as the name suggests, sought to use system fonts in lieu of Open Sans. Here is how it described itself (and you can also visit this page for some sample screenshots):
‚ÄúWhen a visual and small screen admin refresh was introduced in 3.8 (by way of the feature plugin MP6), the admin font was changed to Open Sans to better complement the redesigned vector iconography. This change was not without its bumps or controversy, notably around extended character sets and that it is loaded from Google Fonts for a variety of reasons.
Instead of relying on an external resource, Font Natively moves the WordPress admin back to system fonts. This leads to faster load times, especially when working offline, a removal of a third-party dependency, and a more native-feeling experience as the lines between web experiences and apps continue to blur.‚ÄĚ
Quite obviously, the biggest and most obvious advantage will be that WordPress will shed yet another third-party dependency. This will enhance load times and offer a faster browsing experience for users. That said, it is true that loading Google Fonts hardly takes time, and at best, the difference in load times will not be noticeable either. Furthermore, many WordPress themes use Google Fonts, so the difference in load times will impact on the backend, that is the admin panel. Your website‚Äôs frontend will continue to be as slow or fast as it currently is, obviously.
Furthermore, considering the fact that Open Sans is not truly a necessity in the admin panel, opting for system fonts is surely a wise choice.
Also, there are several places where Google Fonts are not so easily available ‚ÄĒ China, for instance, has restrictions in place on Google products. This shift towards system fonts will help rid users from such issues.
All said and done, relying on system fonts for the admin panel surely makes sense, and I highly doubt if there will be many people who would be opposed to it. In fact, there are many users who rely on a plugin to disable Open Sans anyway, so this proposal is surely the need of the hour. Agreed, homogeneity will be sacrificed, but that is just a small sacrifice to be made, and within a period of time, our eyes will very well adjust to the absence of Open Sans in the admin panel, much like they did to its presence.
However, how exactly will this be implemented? Looking at the changeset in the commit message of Helen Hou-Sandi, the solution being followed is to specify a list of fonts, followed by Sans Serif.
Now, this probably is not the ideal way to put it. There are several users who change the default system font (especially folks on Linux machines, myself included). A good approach would be if WordPress admin panel uses the user‚Äôs choice of the¬†system font. This can be accomplished by specifying only the generic Sans Serif font. However, in the current approach, the admin panel will showcase the specified fonts, not the just user‚Äôs choice of the¬†default font.
Most likely, the team‚Äôs logic behind saying ‚Äúsystem font‚ÄĚ is to refer to fonts that are installed on the system (native to the concerned operating system), rather than the font chosen by the user to act as the system default font. While this is a straightforward line of thought, it would still be better if the user‚Äôs preference is given a priority in this. Many people rely on specific fonts owing to accessibility issues (some fonts are more readable than others), or because they dislike the native font that their OS comes with (some fonts are less ugly than others). Showing the user-specified font will prove beneficial for such users.