Native Fonts in 4.6

When WordPress switched to Open Sans in version 3.8 at the end of 2013, the state of typography on the web was just beginning to evolve. Before, our choices for typefaces were limited to a small subset of fonts reliably installed on most major operating systems. And, in some cases, those fonts were optimized for print, not the web. Open Sans is optimized for the screen, has generous character support, and, best of all, is open sourceOpen Source Open Source denotes software for which the original source code is made freely available and may be redistributed and modified. Open Source **must be** delivered via a licensing model, see GPL.. For these reasons, it was a better option for a modern web app than the system fonts of that time.

Today, the landscape has changed. The majority of our users are now on devices that use great system fonts for their user interface. System fonts load more quickly, have better language support, and make web apps look more like native apps. By using the same font that the user’s device does, WordPress looks more familiar as a result. This change prioritizes consistency from the user’s perspective over consistency in branding. And while typography does play a role in the WordPress brand, the use of color, iconography, and information architecture still feels very much like WordPress.

To this end, Font Natively (#36753) replaces Open Sans with a set of system fonts that covers major operating systems, including Android, iOSiOS The operating system used on iPhones and iPads., Windows, macOS, and Linux.

The Font Stack

Safari, Chrome, and Firefox on iOS and macOS have new CSSCSS Cascading Style Sheets. values that return the current system UIUI User interface font, but on other platforms, the font has to be declared by name. As such, the font stack includes the following:

  • -apple-system for Safari (iOS & macOS) and Firefox macOS
  • BlinkMacSystemFont for Chrome macOS
  • Segoe UI for Windows
  • Roboto for Android and Chrome OS
  • Oxygen-Sans for KDE
  • Ubuntu for Ubuntu
  • Cantarell for GNOME
  • Helvetica Neue for versions of macOS prior to 10.11
  • sans-serif, the standard fallback

The complete CSS declaration: font-family: -apple-system, BlinkMacSystemFont, "Segoe UI", Roboto, Oxygen-Sans, Ubuntu, Cantarell, "Helvetica Neue", sans-serif;


The operating system’s UI font is used for any text that’s part of the WordPress user interface. In other contexts, like the Editor, we continue to use a serif system typeface, Georgia. This creates a clear typographic distinction between text that is part of the interface, and text that is part of the user’s content.

Not all system fonts provide the same range of weights that Open Sans did. We recommend using only the 400 and 600 weights, which will display most consistently across all platforms. I’ve created a test page that shows the difference between Open Sans and your current device’s system font at every available weight. (A collection of screenshots of that test page is also available).

The order in which they’re called is important, because we want the user’s system font to be the first available font in the stack. For example: if Roboto were listed ahead of Segoe UI, Windows developers who have installed the Roboto font for Android development would see it instead of their native system font. There may be edge cases if users have manually installed these fonts on their machines, but this order should work best for the majority of users.

When using this font stack, it must be called using the font-family property, and not the font shorthand. This works around an issue in Microsoft Edge.


All screenshots were taken on a retina (2dppx) device. If you’re reviewing screenshots on a non-retina display, check out this Cloudup gallery of 1x screenshots.

#4-6, #design, #dev-notes, #fonts

Open Sans, bundling vs. linking

In Wednesday’s 3.8 planning meeting we discussed hotlinking vs bundling Open Sans. MP6 followed Twenty Twelve’s example by linking to Google Webfonts, but the consensus from Wednesday’s chat was that bundling would be preferable.

I began experimenting with this last week; first determining which font formats were necessary to include. I settled on WOFF and SVG as the two formats that would cover every browser we’re aiming to support. I left out TTF and EOT as they add only marginal browser support (IE8), but would add significant weight to the WordPress download. We do include TTF and EOT versions of Dashicons, since loading those icons is essential to usability in a way that loading Open Sans is not.

The bundled Open Sans webfonts come from FontSquirrel. The Western Latin and Basic Latin subsets are small and include enough characters for English language support. Those subsets do not include a full set of glyphs for other languages, however (they’re available as separate downloads). There is a non-subsetted version of the font available which includes all necessary glyphs, but it’s 2x–2.5x the file size of the subsetted fonts, which add significant overhead to the pageload and can actually crash some mobile browsers. The Western Latin and Basic Latin subsets can cause missing characters (spaces or boxes) to appear in text using accented characters, which is a significant usability concern.

Google Webfonts solves both the character set and the font format problems by intelligently loading the font format and the character subset that’s needed for a particular browser and a particular website, and nothing more. For us to bundle Open Sans with WordPress, we need a way to accomplish that without adding significant heft to the coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. WP download. I’m starting this P2P2 A free theme for WordPress, known for front-end posting, used by WordPress for development updates and project management. See our main development blog and other workgroup blogs. thread to open up the discussion on how we might do that.

#3-8, #fonts, #open-sans