How to Use Cross Browser Web Fonts, Part 2

Share this article

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.

Frequently Asked Questions about Cross-Browser Web Fonts

What are cross-browser web fonts and why are they important?

Cross-browser web fonts are fonts that are designed to be compatible and display correctly across different web browsers. They are important because they ensure that your website or web application maintains a consistent look and feel, regardless of the browser that your visitors are using. This is crucial for providing a seamless user experience and maintaining your brand’s visual identity.

How do I use cross-browser web fonts?

To use cross-browser web fonts, you need to include the font files in your website’s CSS. This is typically done using the @font-face rule, which allows you to specify the font file to use, as well as a fallback font in case the specified font cannot be loaded. You can also use web font services like Google Fonts or Adobe Fonts, which host the font files for you and provide you with the necessary CSS code to include in your website.

What is the Abril Fatface font and where can I get it?

Abril Fatface is a typeface inspired by the heavy titling fonts used in advertising posters in 19th century Britain and France. It has a bold, dramatic look that is great for headlines and other large text. You can download Abril Fatface for free from Google Fonts, Font Squirrel, and 1001 Free Fonts.

How do I ensure that my web fonts display correctly in all browsers?

To ensure that your web fonts display correctly in all browsers, you should include multiple font formats in your @font-face rule. This is because different browsers support different font formats. For example, Internet Explorer only supports EOT fonts, while Safari and Opera only support OTF and TTF fonts. By including multiple formats, you can ensure that your font will display correctly in all browsers.

What are some common issues with using web fonts and how can I solve them?

Some common issues with using web fonts include fonts not loading, fonts displaying incorrectly, and performance issues. These issues can often be solved by ensuring that your font files are correctly formatted and hosted, that your CSS code is correct, and that your font files are optimized for web use. If you’re using a web font service, they will typically handle these issues for you.

Can I use web fonts in my email campaigns?

Yes, you can use web fonts in your email campaigns. However, not all email clients support web fonts, so you should always include a fallback font in your CSS. This ensures that your email will still look good even if the web font cannot be loaded.

How do I choose the right web font for my website?

Choosing the right web font for your website depends on your brand’s visual identity and the content of your website. You should choose a font that matches your brand’s personality and that is easy to read. You can also use tools like Google Fonts, which allow you to preview different fonts and see how they look on your website.

What is the difference between a web font and a system font?

A web font is a font that is downloaded from the internet when a webpage is loaded, while a system font is a font that is installed on a user’s computer. Web fonts allow you to use a wider range of fonts on your website, but they can also slow down your page load times if not properly optimized.

How do I optimize my web fonts for performance?

To optimize your web fonts for performance, you should minimize the number of font files that you use, use font formats that are optimized for the web, and use CSS techniques like font subsetting and font loading optimization. You can also use a web font service, which will handle these optimizations for you.

Can I create my own web font?

Yes, you can create your own web font. There are several tools available that allow you to convert your own font designs into web font formats. However, creating a web font requires a good understanding of typography and font design, as well as the technical aspects of web font creation.

Chris MillsChris Mills
View Author

Chris Mills is a senior tech writer at Mozilla, where he writes docs and demos about open web apps, Firefox OS, and related subjects. He loves tinkering around with HTML, CSS, JavaScript and other web technologies, and gives occasional tech talks at conferences and universities. He used to work for Opera and W3C, and enjoys playing heavy metal drums and drinking good beer. He lives near Manchester, UK, with his good lady and three beautiful children.

cross-browserCSSCSS3font-facefontfacefontsweb font
Share this article
Read Next
Get the freshest news and resources for developers, designers and digital creators in your inbox each week