Web

How to Use Cross Browser Web Fonts, Part 2

Chris Mills
Share

Introduction

In part 1 of my article (https://www.sitepoint.com/how-to-use-cross-browser-web-fonts-part-1/) I introduced web font syntax, looking at how basic @font-face and font-family syntax can work together to embed custom fonts on your web pages, and the slightly more complex cross browser reality.

In this part we'll go further, looking at common real world issues associated with web fonts, and comparing free and paid options for hosting your fonts.

The third part will look at some of the more advanced CSS font features, such as hyphenate and font-feature-settings.

Cross Browser Web Fonts – Problems

So you've got your fonts up on your server and your cross browser @font-face code in place. Check. But your problems might not be over. In this section I'll look at a few further problems you might encounter, along with suggested solutions.

Bad rendering

Testing across browsers is paramount: even if you don't fall foul of any other problem, the rendering of your fonts might just be plain bad, especially in IE and Chrome/Blink-based Opera on Windows. This can be for a variety of reasons, but the main ones are:

  • Use of ClearType: ClearType is a Windows technology that uses sub-pixel rendering to make fonts appear smoother. If not enabled, fonts can look really bad, although it is turned on by default on most Windows systems (later than XP.) It is still generally not as effective as Mac OSX anti-aliasing. Note that other browsers on Windows don't tend to suffer as much as they tend to have their own sub-pixel rendering systems. For more information, read Jon Tan's "Display type and the raster wars" (http://v1.jontangerine.com/log/2008/11/display-type-and-the-raster-wars)

  • Google Web Fonts rendering has been messed up in the Blink rendering engine for a while now due to various reasons: check out the following bug report for the saga (https://code.google.com/p/chromium/issues/detail?id=137692)

  • Some fonts (most likely free ones) can have a low number of glyphs available, meaning that when you use a character in your content for which a glyph is not available in the font you are using, you will get a nasty rendering surprise such as blank spaces of the dreaded ugly squares of doom, instead of the characters you expected. To mitigate such negative effects, you should make sure you always include a fall-back font in the stack, even if you are using a web font, for example

font-family: 'Abril Fatface Regular', arial, sans-serif;

FOUT

FOUT stands for Flash of Unstyled Text, and — while it isn't so much of a problem anymore, only affecting early Firefox and Opera versions and IE < 10 — you might still come across it and want to do something about it. This is when you get unstyled text appearing on your page while the HTML has loaded but the web font hasn't yet done so.

There are a number of font-related libraries and techniques available to deal with FOUT, many of which are mentioned in Paul Irish's "Fighting the @font-face FOUT" (http://www.paulirish.com/2009/fighting-the-font-face-fout/). I personally found the most reliable technique to be Google's Web Font loader (https://developers.google.com/fonts/docs/webfont_loader). This contains JavaScript that detects whether your web fonts have loaded yet and applies classes to the document's tag to indicate their status. You could use these to hide elements until their fonts have loaded, for example:

.wf-loading h1 {
  visibility: hidden;
}

Then when the required font has loaded, a specific class is added to the tag to indicate this, and you can update the element's display as appropriate:

.wf-lobster-n4-active h1 {
  visibility: visible;
  font-family: lobster;
}

High bandwidth

Adding web fonts to your page will obviously mean a performance hit, which will be negligible in many cases as a web font will probably be around 50-100KB (as a very rough guess!) You should limit the number of fonts you use on each page for both bandwidth and performance reasons, but even a single font can be very large, especially if it is a CJK font (http://en.wikipedia.org/wiki/CJK) that can have thousands of glyphs inside it.

To mitigate this problem, you can either:

  • Create a modified font file containing only the characters you need. To do this, you need a font editor such as Font Forge (http://fontforge.org/).
  • Specify only the characters you want to use out of the font file by using the unicode-range property inside your @font-face block that we saw in the last part of my series. For example:
@font-face {
  font-family: 'Abril Fatface';
  src: url("AbrilFatface.otf");
  unicode-range: U+0026;
}

This specifies to only load the ampersand character from the font (see https://www.w3.org/TR/css3-fonts/#unicode-range-desc for more info on specifying multiple characters, including ranges). unicode-range is supported well across modern browsers, with the notable exception being Firefox (we're working on it!). If you want to use unicode-range on Firefox or older browsers, you could use a polyfill such as jquery-unicode-range (https://github.com/infojunkie/jquery-unicode-range).

Browser bugs and idiosyncracies

There are a few browser bugs I also thought I'd also mention, for interest's sake.

IE9 bug with downloading EOT

If you use the bulletproof @font-face syntax we explored in the last article, IE9 and later will download the EOT version of the font and use that, which is a bit of a pain.

Cross domain font fail

As per the spec, you can't load fonts from a different domain to your CSS (although Chrome, Safari and Opera incorrectly allow this.) To get around this restriction you could consider using CORS (see http://dev.opera.com/articles/view/dom-access-control-using-cross-origin-resource-sharing/)

IE 6-8 downloads fonts that are declared and not used

You should never declare @font-face rules for fonts that you don't end up using on your page; IE6-8 will download them all anyway.

Serving fonts from an IIS server

If you are serving fonts from an IIS server, you'll need to add ‘.woff’ with a MIME type of ‘application/x-font-woff’ to your IIS installation, even though WOFF doesn't have a MIME-type. IIS refuses to serve anything that it doesn't have a MIME type for.

Self hosting versus hosted services

With @font-face quirks and bugs discussed, let's round this article off with a brief look at some different options for acquiring and hosting fonts. Self-hosting fonts is more costly in terms of bandwidth, and more fiddly to set up, but you tend to get more precise control over how you are implementing fonts on your sites. On the other hand, using a hosted service is quicker to set up (the service deals with all the cross browser quirks, etc. for you) and someone else is hosting the fonts for you.

Note: some of the mechanisms here are free, and some are paid. There are a number of high quality free font resources available, but you get what you pay for: even high quality free fonts tend to suffer in some way, either by having a limited character set or variants available, or simply by being overused on the web. If you want something deep and truly original for your publication, you are better off looking at a paid solution.

Free font sources I'd recommend are: Font Squirrel (http://www.fontsquirrel.com/), Da Font (http://www.dafont.com/), League of Movable Type (http://www.theleagueofmoveabletype.com/) and Lost Type (http://www.losttype.com/browse/). Best Free Fonts for Designers by Jad Limcaco (http://www.smashingmagazine.com/2011/07/19/best-free-fonts-designers/) has some more suggestions and good advice.

Paid font sources I'd recommend: Hoefler and Frere-Jones (http://www.typography.com/), Linotype (http://www.linotype.com/) and House Industries (http://www.houseind.com/). There are many other good sources too!

Google Fonts

Google Fonts is a free hosted font service, available at http://www.google.com/fonts. This is a great service with reasonable quality fonts, and really easy to use; great for writing quick and dirty demos, and putting together a site on a budget. It suffers from the same troubles as any free font resource: some of the better fonts get overused, and the options you get are quite limited.

Paid hosted font services

There are now a number of paid hosted font services, and they all work in a similar fashion. You generally:

  1. Sign up for the service
  2. Specify the domain(s) that you want to use your fonts on
  3. Specify the fonts you want to use
  4. Paste some custom CSS and sometimes JavaScript into your site that handles the @font-face and font-family coding
  5. Test your font choices in some way or another
  6. Pay for the fonts when your sites are put live, usually per font, per site, per year.

I have tried a number of these services, but my favourite two are as follows:

  1. Typekit (https://typekit.com/): an Adobe-owned service, with slightly pricey usage plans that covers multiple sites and font usage, and work out OK for larger scale operations. You can also get a limited free plan that is good enough for testing, but only two fonts at a time.
  2. Font Deck (http://fontdeck.com/): an independent type company from the UK that offers a free plan that allows testing of a number of fonts per site, but only when accessed by a limited number of IP addresses. Production fonts cost around $7.50 per font per year. I like this service marginally more because I've found the testing functionality more useful, and they also offer some nice opentype font features.

Note: Dan Eden's Web Font Services: the Good, the Bad, and the Ugly (http://webdesign.tutsplus.com/articles/typography-articles/web-font-services-the-good-the-bad-and-the-ugly/) is a nice article with some further information on web font services.

The benefits are usually apparent when you start to use such services: you'll have access to high quality fonts with full glyph sets and multiple weights and variants on offer. You'll also be able to find opentype fonts with opentype features available such as stylistic swashes and ligatures, which can be utilized on the Web using the nascent font-feature-settings property. This is one thing we'll look at in part 3 of the series.