WordPress.org

Ready to get started?Download WordPress

Make WordPress Core

Updates from Matt (Thomas) Miklic Toggle Comment Threads | Keyboard Shortcuts

  • Matt (Thomas) Miklic 7:33 pm on November 11, 2013 Permalink
    Tags: , fonts, open sans   

    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 core WP download. I’m starting this P2 thread to open up the discussion on how we might do that.

     
    • Matt Mullenweg 7:43 pm on November 11, 2013 Permalink | Log in to Reply

      It’s also worth noting if we can solve this in a standalone way (the script not loading any of the rest of WP) we avoid licensing issues and also solve a general problem many people across the web have.

      Also keep in mind if this takes longer than a few days the right answer for 3.8 might be linking in core and releasing a plugin for people that bundles for people that don’t like Google.

      • Piet 4:28 am on November 12, 2013 Permalink | Log in to Reply

        I think it doesn’t have so much to do with liking or not liking Google. There are certain countries where Google is blocked and that includes loading their fonts. For all sites I built (I live in China), I bundle fonts, because only then I can be sure that these fonts load.
        That might be another argument pro-bundling :)

        • krembo99 6:03 am on December 22, 2013 Permalink | Log in to Reply

          I am with Piet – Have the same problems in china ( and elsewhere – granted – all totalitarian regimes, but still .. ). Google services work only sporadically . Fonts , jQuery CDN , Maps etc. Linking those resources makes the page time-out .

    • Doug Wollison 8:41 pm on November 11, 2013 Permalink | Log in to Reply

      Regarding the missing characters, don’t just about all browsers fallback to the next font in the font-family list for those characters?

    • mindctrl 8:46 pm on November 11, 2013 Permalink | Log in to Reply

      Relying on a third party for fonts in core doesn’t make me want to do cartwheels. It’s a backdoor analytics of sorts, and a privacy concern. The increased file size is the lesser of two evils. Neither option is ideal.

      I love Open Sans, but given the two options, I’d rather see Arial. *runs for cover*. I just tested swapping out Open Sans for Arial in trunk, and it’s really not that bad. Theming the WP admin/MP6 via plugins would be a great way for people to opt into hosted font solutions.

      • Doug Wollison 9:21 pm on November 11, 2013 Permalink | Log in to Reply

        Or, the better compromise; Helvetica (Neue if possible), finally falling back to Arial if things get desperate.

        • mindctrl 9:26 pm on November 11, 2013 Permalink | Log in to Reply

          I thought the same thing originally. Helvetica Neue isn’t that bad, but it’s also not standard on a number of platforms. Neither is Helvetica. This was news to me. I don’t know of a definitive list online, but this one from MailChimp is helpful, and the reason I said and tried Arial. http://templates.mailchimp.com/design/typography

          • mindctrl 9:27 pm on November 11, 2013 Permalink | Log in to Reply

            Sorry, actually standard Helvetica is.

            • jwarren 11:09 am on November 13, 2013 Permalink

              If we’re going with system fonts, it should probably just be standard ‘san-serif’, which will be Helvetica on OSX, Arial on Windows, and whatever has been deemed appropriate on the Linux distro of choice. It also allows people and browsers to override that easily for their own purposes – perhaps a different language, perhaps extra visual clarity, perhaps an unusual display technologo… who knows?

    • Robert Dall 9:41 pm on November 11, 2013 Permalink | Log in to Reply

      I have never really like relying on a third party service to do what could be done internally.

      Also what if you are developing locally without access to the internet?

      Regardless of who provides the free service. One day Google (or Adobe who just started there own free font embedding service) “could” turn around and say. “Ya were not going to do that free font thing anymore”

      Now it would be easy to swap it out but why rely on something like that anyways.

      • Matt Thomas 9:50 pm on November 11, 2013 Permalink | Log in to Reply

        To be clear, we’re talking about linking to Google Fonts for Open Sans just until we can solve this in a standalone way, as @matt mentioned above.

        If you’re working locally with no internet connection, the fonts will just fall back to the browser-defined “sans-serif” font (Helvetica on OS X, Arial on Windows by default).

    • Ryan Hellyer 10:04 pm on November 11, 2013 Permalink | Log in to Reply

      I suspect that bundling scripts into WordPress core will create privacy concerns for many people. The ability to perform analytics via them will disturb a small segment of the user-base.

      It may even be illegal in some countries. Germany springs to mind in regards to that. They’re already super ticked off about being spied on at the moment, so I think it might be best if WordPress doesn’t join the party too.

      And yes, you can install a plugin to force them to be self-hosted, but many people will just unwittingly hit the “update” button without ever realising that they’re opening themselves up to privacy issues.

      • Doug Wollison 10:10 pm on November 11, 2013 Permalink | Log in to Reply

        What if we take a progressive enhancement approach? By default, we wouldn’t actually load Open Sans from anywhere, and instead just falls back to whatever font it can. Then we offer plugins (or packaged right in the core) options for self hosted or google hosted.

      • daveshine (David Decker) 11:49 pm on November 11, 2013 Permalink | Log in to Reply

        Almost any modern theme loads Google Fonts already, including some of the default themes, plugins not counted…

        I have absolutely nothing against loading Open Sans from Google, and find it a rather good option to do so.

        Yes, there are lot of issues with privacy that should be done better – in my opinion this topic here falls not amongst them…. just my personal view.

        Thanks, Dave from Germany :)

    • Dion Hulse 11:14 pm on November 11, 2013 Permalink | Log in to Reply

      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.

      If we actually want to use Open Sans for WordPress, this is unfortunately what we have to do.

      • Open Sans (WOFF+SVG for Italic, Regular, SemiBold, and SemIbold+Italic) weighs in at 576K uncompressed (92K WOFF, 484K SVG), 174K compressed.
      • Open Sans (WOFF+SVG for Italic, Regular, SemiBold, and SemIbold+Italic w/ full charset support ) weighs in at 4.5MB uncompressed (345K WOFF, 4.2MB SVG), 826K compressed.

      The SVG’s will compress well as they’re just text, WOFF is already compressed. We could have a light-weight PHP script that served compressed documents intelligently depending upon the client (selectively adding Charsets based on WPLANG / browser UA), but this has caching issues amongst other things.

      If we actually look at what the fonts are for though…

      • WOFF is the primary font, it’s supported by most browsers.
      • SVG is included for iOS 3.2-4.3 support, and for Android Browser 4.0-4.3.

      Given the significant size of SVG fonts, it makes me question if we should be using them at all, it doesn’t add much extra browser support.

      An alternative is shipping with WOFF+TTF fonts – that would add support for iOS 4.2-4.3 (iOS 3.2 misses out), and Android 2.2-4.3 (SVG only works for 4.0-4.3).

      • Open Sans (WOFF+TTF for Italic, Regular, SemiBold, and SemIbold+Italic w/ full charset support ) weighs in at 1,000K uncompressed (345K WOFF, 661KB TTF), 689K compressed.

      or.. just drop Open Sans for those mobile clients.. since it really doesn’t seem worth it.. WOFF supports most desktop browsers and modern mobile devices, and we should have a GOOD font fallback list for unsupported browsers (which we don’t currently have with MP6, but we did previously have in WP 3.6).

      • Dion Hulse 11:22 pm on November 11, 2013 Permalink | Log in to Reply

        I also missed that SVG is also for Mac Safari 3.2-5.0, not just for iOS. TTF is supported in Safari 3.1-5.0 as well.
        TTF/SVG is also needed for older Opera versions (desktop and mobile, and some gaming systems), but WOFF is supported for v11+ so that doesn’t seem like a deal breaker at all (coming from an Opera user..)

      • Matt Thomas 11:48 pm on November 11, 2013 Permalink | Log in to Reply

        I don’t recommend using the un-subsetted font for any solution because of the extra page weight that every user would incur. Intelligently loading the correct subset for the specified language is the best possible user experience, whether it’s linked to from Google fonts or we implement our own solution that accomplishes the same result. Just for comparison, this is the size difference for a single weight and style of Open Sans (we need four: regular, italic, semibold, and semibold italic).

        • English subset, WOFF: 13 KB
        • Czech subset, WOFF: 17 KB
        • Full charset, WOFF: 85 KB
        • English subset, SVG: 32 KB
        • Czech subset, SVG: 70 KB
        • Full charset, SVG: 1.1 MB
        • Dion Hulse 12:01 am on November 12, 2013 Permalink | Log in to Reply

          So yes, I’d never suggest SVG for this.. ever..

          WOFF however, we can get away with including the full set, the extra page load isn’t significant once it’s in the cache.

          Most web services will get away with only loading one subset as they know what the characters on the page are, WordPress doesn’t really know the answer to this, French accented characters can appear in an English post, etc.. so relying upon WPLANG is a rather bad idea for this.

          One method would be to have Javascript detect the characters on the page and load the english by default, and optionally load the larger CSS if it spots any of those characters..

          Even Google Fonts requires you to specify which subsets you want to load, it can’t automatically guess what’s on the page.. so it’ll have the same page load issues (except that you gain benefit from their extra-special browser compression and CDN).

    • davelab6 5:30 am on November 12, 2013 Permalink | Log in to Reply

      Disclaimer: I consult for Google, Adobe and other companies on web fonts and libre fonts issues, but I represent only myself. This is my own personal opinion.

      One day Google (or Adobe who just started there own free font embedding service) “could” turn around and say. “Ya were not going to do that free font thing anymore”

      Anyone can see that Google uses the Fonts API for its own web apps and web pages. Since the fonts are libre licensed, if that day ever comes, switching is possible.

      If you’re working locally with no internet connection, the fonts will just fall back to the browser-defined “sans-serif” font (Helvetica on OS X, Arial on Windows by default).

      If you’re working locally, you can install the fonts, and if the CSS includes them with ‘local’ (as the Google Fonts API css does) then they’ll load :)

      For WordPress to self host the fonts, in a way that matches the fonts served by Google’s Fonts API, you’ll want to subset them by language, and also have versions with the hinting removed to serve to browsers on platforms that don’t use hints, and perhaps also CFF versions for platforms with good CFF rendering. Since WordPress doesn’t have a dynamic font subsetter, you’ll need a set of language subsets and a set of hint subsets.

      WOFF, SVG, TTF, EOT is needed for full browser support, in descending order of importance. If you leave out formats, you will leave out users. Maybe that matters, maybe it doesn’t.

      By using the Google Fonts API you support all users on all platforms. The API doesn’t carry a cookie, so there aren’t the same privacy implications.

      • Matt Thomas 4:15 pm on November 18, 2013 Permalink | Log in to Reply

        Thanks Dave, this is good information to have. Aside from the font format issue — I think we could get by with WOFF and SVG or TTF, based on the browsers we have chosen to support (others would just fall back to browser-standard sans-serif as in 3.7). But hinting and internationalization are big issues that will be thorny to solve with a bundled solution.

    • jwarren 11:14 am on November 13, 2013 Permalink | Log in to Reply

      I would suggest that bundling would be ideal – who know what strange systems WordPress could be running on if/when Google eventually deprecates their fonts service? It also keeps the experience consistent for any isolated environments. Local development away from a consistent internet connection is not an infrequent occurrence, and the fewer 404s, the better.

    • toscho 3:17 am on November 17, 2013 Permalink | Log in to Reply

      MIME types for fonts are not always set up properly on the web server. I just had such a case recently, where the browser showed garbage on first load because of that. The second load took the fonts from cache, and the browser applied the correct glyphs.

    • Louy Alakkad 2:25 pm on November 17, 2013 Permalink | Log in to Reply

      How about using the ‘open-sans’ fonts by default and giving the user three options in theme settings, first is open-sans, second is google fonts and third is downloading a plugin that contains all the fonts needed?

    • Anderton 1:08 am on November 18, 2013 Permalink | Log in to Reply

      Also, Google is blocked in some countries (i could for example not use Google Fonts in China now and then). Now this is no issue with the bundling open san. But for reference: http://www.google.com/transparencyreport/traffic/disruptions/#expand=Y2013

    • Milan Dinić 4:50 pm on November 18, 2013 Permalink | Log in to Reply

      I vote for ditching Open Sans for reasons already mentioned in this thread:

      • Why would we all of sudden rely on external service for essential part of WordPress that is admin area? Then why don’t we also load jQuery from Google, at least that way there would be real benefit since it would save billions of request?
      • Why would we decide which subset to use based just on WPLANG? What with those that use admin in English even though content is in other language? What for multilanguage? Some browsers don’t do proper fallback and we’ll end with squares and other garbage. If Open Sans gets in, all subsets should be included, that’s the price of using nonstandard font.
      • Possible server issues.
    • mor10 7:41 pm on November 19, 2013 Permalink | Log in to Reply

      For the default theme any custom font needs to be bundled for a simple reason: Not every WordPress installation runs on a computer connected to the web. There are many scenarios in which the site is not connected to the web: It could be a standalone application entirely severed from any network, it could be a site hosted on a secure intranet, the list goes on. As an external font library would result in a non-standard experience for these use scenarios I would encourage the inclusion of any custom font in the package itself. And for those same scenarios the inclusion of TTF and EOT might well be necessary since many of these users (European hospital intranets is one example) are stuck behind old system architecture that doesn’t support IE9 and above. Keep in mind that IE9 requires Windows 7, an update not yet undertaken by large parts of government and large industry landscapes.

    • Milan Dinić 5:11 pm on November 28, 2013 Permalink | Log in to Reply

      I have coded a simple plugin that disables loading of Open Sans from Google’s servers. If you have any comments about it (including its name), please share and I’ll submit it to repository in a few days.

    • mighty_mt 7:34 pm on December 10, 2013 Permalink | Log in to Reply

      So what’s the status here? I see in 3.8-RC2 (and also in MP6 2.2.1) that Open Sans is still loaded from Google. And to be honest, I don’t like that.
      I also think that WordPress shouldn’t use web fonts for the admin at all (especially not ones loaded from third party servers). Even though the new admin looks very pretty with Open Sans.

    • Alex Nguyen 1:48 am on December 15, 2013 Permalink | Log in to Reply

      Is there any way to disable Open Sans in the new 3.8 update? My blog is in Vietnamese and Open Sans does not display Vietnamese characters properly.

    • Paul 8:36 pm on December 19, 2013 Permalink | Log in to Reply

      Would love to dequeue open sans, it was a lovely idea but on a unstable african ISP its making editing on a clients site an unbearable experience – and I’m fairly privileged – honestly a standard stack would suit me fine, or just ‘sans-serif as someone suggested above.’. I really don’t thing open sans looks that great to boot.

    • ElectricFeet 12:44 pm on February 19, 2014 Permalink | Log in to Reply

      If it must be linked and not bundled (and I defer to your expertise on that decision), the best option would be to have a simple checkbox in “Edit my profile”: Use Google fonts for admin area?

      Apart from privacy concerns, linking on local dev environments really slows things down.

      (I’m using Milan’s plugin for now. Thatnks Milan!)

    • owcv 4:23 pm on February 24, 2014 Permalink | Log in to Reply

      I’m not happy with this kind of integration of Google on my WordPress Website. I don’t want big brother to watch my site. Open Sans should be included in WordPress but not linked to Google. At least there should be an option to deactivate for users in countries with certain information privacy policies. In the EU for example this could be a violation of actual law!

  • Matt (Thomas) Miklic 4:52 pm on July 13, 2010 Permalink
    Tags: ,   

    Made some minor style updates to the wporg web site today; changed the dark grey and light blue backgrounds to lighter shades of grey to better match the 3.0 style, as requested by Matt M. Replaced homepage screenshots with new ones from 3.0, as requested by Jane.

     
c
compose new post
j
next post/next comment
k
previous post/previous comment
r
reply
e
edit
o
show/hide comments
t
go to top
l
go to login
h
show/hide help
shift + esc
cancel