The Typekit Blog

As part of our ongoing work to improve type rendering, we’re rolling out some changes to the font outlines we deliver. To explain how this works, let’s first review how font files are rendered, and then look at some examples to show how we can improve upon them.

In previous posts, we’ve discussed how font files typically include outlines in one of two formats: TrueType or PostScript. TrueType outlines can include detailed instructions (usually referred to as “hints”) which provide additional information to the rendering engine. Hints can resolve the warts and inconsistent stroke widths that plague fonts in Windows browsers.

At small sizes (and especially when a font has been well-hinted), the Windows GDI rendering engine, with ClearType enabled, makes for clear, crisp rendering. But GDI’s ClearType subpixel antialiasing only works in one direction (horizontally). GDI ClearType does not smooth letterforms vertically, so diagonal strokes and curved strokes — especially at large sizes – can look pixellated, even if a font is well hinted.

Bello Pro, TrueType outlines, GDI ClearType. Note the ugly stepping effect on the curved horizontal strokes, due to a lack of vertical smoothing.

Close up look at Bello Pro under GDI ClearType.

DirectWrite — the default rendering engine in IE9, and enabled via a user preference in Firefox 4 — corrects this problem; it uses ClearType subpixel antialiasing for horizontal smoothing, and also smooths letterforms vertically. However, many users have yet to upgrade and are stuck with GDI ClearType. And unfortunately, no amount of hinting can correct this.

There is a solution, however: due to a quirk in the GDI rendering engine, PostScript outlines cannot be rendered with ClearType, but rather display using grayscale antialiasing. Grayscale antialiasing smooths in both directions, and looks great at large sizes. So we can improve this rendering scenario by serving PostScript outlines instead of TrueType.

Bello Pro: TrueType outlines on the left, PostScript on the right, both in Windows GDI with ClearType enabled. The PostScript outlines render dramatically smoother.

Starting today, we’re serving PostScript outlines for a number of fonts: Underware’s Bello Pro, as well as Calluna, Lapture Display, and Quatro. In each case, the rendering of the font is significantly improved:

Calluna: TrueType outlines on the left, PostScript on the right.

Lapture Display: TrueType outlines on the left, PostScript on the right.

Quatro: TrueType outlines on the left, PostScript on the right.

If you’re using these fonts, republish your kits to get the updates. We’re working closely with our foundry partners to identify additional fonts in the library that would also benefit from PostScript serving, and we’ll be rolling those out as we can. Stay tuned!

With some of the recent improvements to our kits, Typekit is providing more tools for using fonts on the web than ever before. The options range from basic and drop-dead simple (just add fonts and selectors, then drop in the JavaScript) to the more complex (taking advantage of variation-specific font-family names to work around style-linking limitations in old versions of Internet Explorer), and everything in between:

/* Option 1: Add selectors to your kit and don't write any CSS */

/* Option 2: Use Typekit font-family names */
font-family: proxima-nova, sans-serif;

/* Option 3: Use font-weight and font-style
 * to use more fonts within a family */
font-family: proxima-nova, sans-serif;
font-style: normal;
font-weight: 900;

/* Option 4: Use variation-specific font-family names
 * to work around IE bugs */
font-family: proxima-nova-n9, proxima-nova, sans-serif;
font-style: normal;
font-weight: 900;

With all of these different options, it’s useful to step back and consider them as a whole. How do all of these options work, and which factors determine the option that’s right for your project?

Option 1: Don’t write any CSS at all

The first and simplest option is to let your kit add all of the CSS that’s necessary to apply fonts to your page. In the Kit Editor, just add CSS selectors to each of the font families in your kit.

You can add CSS selectors directly to your kit in the Kit Editor.

Publish the kit, and it will automatically include its own CSS when it’s added to the page. All you have to do is add two short lines of JavaScript to the <head> of your page:

<script type="text/javascript" src="http://use.typekit.com/xxxxxxx.js"></script>
<script type="text/javascript">try{Typekit.load();}catch(e){}</script>

Use this option:

• When you don’t want to write any additional CSS yourself
• When you can’t add new CSS to the page

Option 2: Use Typekit font-family names

The next option is to write the Typekit font-family name for each family into your own CSS. You can find the font-family names for each family inside the Kit Editor. Just select a family on the right and then click on “Using fonts in CSS” in the Selectors section on the left. You’ll see the font-family name to use, as well as additional examples of how to write CSS rules.

Click “Using fonts in CSS” in the Kit Editor to find the CSS font-family names to use.

After including the Typekit JavaScript snippet in the <head>, just add the font-family names to the CSS rules in your own stylesheet. For example, to style all the headings on my page in Proxima Nova, I might add this to my stylesheet:

h1, h2, h3, h4, h5, h6 {
  font-family: proxima-nova, sans-serif;
}

Remember to include your own fallback fonts in case the web fonts fail to load for some users.

Use this option:

• When you want your font definitions and the rest of your CSS together in one place
• When you’re using the basic four weights and styles of a font family in your kit

Option 3: Add font-weight and font-style

If you’ve used the font-weight CSS property before, you’re probably most familiar with two values: normal and bold. But the CSS spec also defines a whole range of numeric values from 100 to 900. When you use font-weight: normal and font-weight: bold in your CSS, browsers automatically find the font mapped to the nearest numeric font-weight (400 for normal and 700 for bold).

By default, Typekit selects a basic set of four weights and styles from each font family when you add them to your kit. It chooses fonts as close to 400 (normal) weight and 700 (bold) weight in both normal and italic styles, so that font-weight: normal and font-weight: bold just work. You can add additional weights and styles for each font family in the Kit Editor under the Weights & Styles section on the left.

A basic set of four weights and styles are enabled by default, but you can enable more in the Kit Editor.

If you’re using weights in your kit other than the ones that are selected by default, or you’re using more than two weights in a given family, you may need to define numeric font-weight values in your CSS instead of relying on the normal and bold values. You’ll find the correct numeric font-weight values to use in the Kit Editor. Just select a font family on the right and then click “Using weights & styles in CSS” in the weights and styles section on the left.

Click “Using weights & styles in CSS” in the Kit Editor to find the numeric font weights and styles to use in your CSS.

Copy the numeric font-weight for the specific font that you want, or use the handy “Copy CSS” buttons to copy the font-family, font-style, and font-weight for each font in one click.

For example, what if I added the 300, 600, and 800 weights of Proxima Nova to my kit, and I wanted to use the 600 weight italic variation for headings on my page? By default, browsers might select the 800 weight as the bold weight for headings, but I can be more specific in my own CSS to ensure I get the exact font I want:

h1, h2, h3, h4, h5, h6 {
  font-family: proxima-nova, sans-serif;
  font-style: italic;
  font-weight: 600;
}

Use this option:

• When you’re using weights that don’t map to normal and bold by default
• When you’re using more than than two weights in a single font family

Option 4: Add variation-specific font-family names

While most modern browsers follow the CSS3 draft spec pretty faithfully when it comes to @font-face, the older Internet Explorer browsers have a few limitations. The biggest limitation is that in IE6, IE7, and IE8, you can only link up to four fonts with two weights into a single font-family name before the entire family stops working. In IE8, there are additional @font-face bugs that are triggered by having more than one font linked to a font-family name, which we wrote about in more detail recently.

In order to avoid breaking things completely in these older browsers, Typekit filters the set of fonts that you select in each family down to a basic four weights and styles when serving fonts to these browsers. The downside is that you no longer have access to any additional weights and styles through the main font-family name.

The solution is to add additional variation-specific font-family names to your font stack. Typekit serves these additional variation-specific families only to IE6-8. Each of these families contains only a single weight and style, which means that they won’t trigger any of Internet Explorer’s style-linking bugs.

You can see the variation-specific font-family names for each weight and style of a family in the Kit Editor. Select a font family and then click “Using weights & styles in CSS” in the weights and styles section on the left. At the bottom, check the box to show variation-specific styles, and they will appear in the table above. Once visible, you can copy them in one click using the copy CSS buttons.

Check the box to view variation-specific font-family names in the Kit Editor.

To make use of them, copy these variation-specific font-family names and include them as the first item in your font-family stack. These font-family names are only defined in IE 6-8, so they’ll get used in these older browsers. Newer browsers will fall through to the normal font-family name and make full use of style-linking instead.

In my previous example, if I wanted to make sure that the display of my Proxima Nova headings was totally consistent in IE6-8 when I added three weights to my kit, I could include the variation-specific font-family name for the 600 weight italic Proxima Nova as the first name in my font-family stack:

h1, h2, h3, h4, h5, h6 {
  font-family: proxima-nova-i6, proxima-nova, sans-serif;
  font-style: italic;
  font-weight: 600;
}

Use this option:

• If you’re using more than two weights in a single font family and want to ensure consistent rendering in IE6-8
• If you’re using more than one font in a family and run into any of the IE8 style-linking bugs that we outlined in our previous post

Every project is different, so it’s nice to have an array of options for using Typekit fonts at your disposal. When starting a new project, you can use the guide above and your own comfort level to decide which option works best for you. Happy developing!

We recently launched an improvement in our support for older versions of Internet Explorer. In newly published kits, we now serve additional variation-specific font-family names to IE 6-8. This makes it possible to work around bugs in these browsers that are triggered when multiple weights and styles of a single font family are used in the same kit. Most importantly, these additional font-family names make it possible to use more than four weights and styles of a single font family in IE 6-8. Here’s an example a new variation-specific name in use:

h1 {
  font-family: proxima-nova-n1, proxima-nova, sans-serif;
  font-weight: 100;
}

Because some of these bugs are rare, and because we provide automatic workarounds when fewer weights and styles are used, many users won’t have to worry about these additional family names at all. However, for users that do encounter problems, adding a workaround is now quick and easy. Just republish to get the additional variation-specific font-family names in your kit.

Font families with multiple weights and styles

First, some background. The W3C draft specification for the CSS3 fonts module describes the @font-face CSS rule, which Typekit uses to make web fonts available on your sites. The spec describes the ability to define a font-family using multiple @font-face rules, assigning a particular font-weight and font-style to each individual font in the family. These individual fonts are subsequently selected by setting the font-family once and changing the values of font-style and font-weight to match what was defined in the @font-face rules.

@font-face {
  font-family: proxima-nova;
  font-style: normal;
  font-weight: 400;
  src: url("proximaNovaRegular.woff") format("woff");
}
@font-face {
  font-family: proxima-nova;
  font-style: normal;
  font-weight: 700;
  src: url("proximaNovaBold.woff") format("woff");
}

#page-title {
  font-family: proxima-nova, sans-serif;
  font-style: normal;
  font-weight: 700;
}
#page-title .subtitle {
  font-weight: 400;
}

In the previous example, there are two @font-face rules defining a family called proxima-nova. This family contains normal and bold weight fonts. In the CSS, these weights are selected by simply changing the font-weight (as we’ve done with the rules for #page-title and #page-subtitle).

Linking multiple fonts into a single font-family name allows us to access the individual weights and styles within the family with ease. As a bonus, when default rules for weight and style are applied by the browser (like bold for <strong> and italic for <em>), the correct fonts from the family are automatically selected, because the relationship between fonts has been properly described in a way that browsers can understand.

This is much better than linking each weight and style into a separate font-family name (like "ProximaNovaRegular"). Having a separate font-family name for each weight and style requires us to redefine the entire font-family stack (including fallbacks) over and over every time a new weight or style is called for. It also breaks browser default styles, and worse, it can cause some browsers to synthesize faux bold and oblique styles for fonts.

Using variation-specific names in IE 6-8

Unfortunately, not all browsers conform to the specification when it comes to @font-face. In particular, IE 6-8 have some bugs that limit the usefulness of linking multiple fonts into a single family.

The biggest bug prevents us from linking more than four weights and styles into a family in all three browsers. Other bugs that only affect IE8 are triggered by families when more than one weight and style is linked. In these cases, we must give up some of the convenience of linking multiple weights and styles for the sake of compatibility.

That’s where Typekit’s newly added variation-specific font-family names come in. These additional families are only added in IE 6-8, and they make it possible to work around the bugs and limitations in these older browsers. They’re designed to be added at the beginning of a font-family stack as needed, before the main Typekit family name:

#post-title {
  font-family: proxima-nova-n6, proxima-nova, sans-serif;
  font-style: normal;
  font-weight: 600;
}

The first variation-specific name is only defined in IE 6-8, so those browsers will make use of the unlinked family name. Browsers that don’t have issues with linking will make use of the full family name that comes second in the stack, since the variation-specific name is undefined in those browsers.

These additional family names each contain a single font, so they’re guaranteed not to trigger bugs related to linking multiple weights and styles. The names consist of the normal font-family name, followed by a dash, followed by a font variation description (or FVD). So, for example, the variation-specific font-family name for proxima-nova that contains only the italic 400 weight font would be proxima-nova-i4. If your kit uses the old style segmented font-family names (like proxima-nova-1, proxima-nova-2), simply strip off the trailing number and add the FVD (again, proxima-nova-i4).

You can easily find the appropriate variation-specific font-family name for each weight and style within the Kit Editor. Select a family on the right, then click “Using weights & styles in CSS” on the left and check the box at the bottom to show variation-specific names. Use the handy button to copy font-family, font-style, and font-weight CSS declarations in one click.

Click "Using weights & styles in CSS" and check the box at the bottom to see variation-specific font-family names in the Kit Editor.

Many users won’t need to make use of these additional font-family names at all. You’ll only need to add them if you’re trying to work around any of the following issues:

Trying to use more than four weights and styles in a single family in IE 6-8

All three of the older IE browsers have a bug that limits them to four weights and styles linked to a single font-family name. In these browsers, Typekit has always filtered the enabled weights and styles down to fit within the constraints. If you want to use more than the filtered set in these browsers, you can now use variation-specific font-family names to get around the limitation.

Certain weights not showing up in IE8 when used in combination with other weights

Aside from the four weights and styles limitation, IE8 has additional limitations. Certain combinations of weights don’t work together when linked into the same font-family name. Using variation-specific names is a valid workaround for this problem.

Spacing randomly changing between page refreshes in IE8

When more than a single weight or style is linked to a font-family name, IE8 has a few more bugs that crop up occasionally. IE8 will sometimes randomly alter the letter spacing or line height of fonts when any linking is used. Adding a variation-specific font-family name prevents this bug from triggering.

Fonts on the page randomly changing when using iframes in IE8

Another bug triggered by linking in IE8 causes fonts to flicker, appear, or disappear randomly when iframes are used on the page. This is commonly seen when using components that use iframes under the covers, like the Facebook “Like” button or certain modal dialogs that display content from other pages. Adding a variation-specific font-family name works here as well.

Again, if you’re not experiencing problems in IE 6-8, you don’t need to worry about variation-specific font-family names. In fact, many users won’t have to use them, because they’re using weights and styles that don’t happen to trigger a bug. But when problems do arise, these additional font-family names provide a powerful workaround for these older browsers.

We’ve just launched some improvements to the way that kits are created and used. These changes make it easier to use fonts from your kit in your own CSS and give you a better default set of weights and styles when you add families to your kit.

New kits have single font-family names

First, we’ve changed the CSS font-family names for fonts in newly created kits. Existing kits use two different font-family names ending in -1 and -2. This is because we have historically separated the characters in a font into two different files as a means of protecting the font, but we no longer use this method of font protection. As a result, all new kits now use a single font-family name:

#page-title {
  /* Old style */
  font-family: proxima-nova-1, proxima-nova-2, sans-serif;

  /* New style */
  font-family: proxima-nova, sans-serif;
}

Only newly created kits will use the new font-family name style. Older kits will never change their font-family names — even after republishing — because it would require users to change all of the font-related CSS on their site at the same time. If you’d like to migrate an existing site to the new naming convention, we recommend creating a new kit.

It’s important to remember that the CSS font-family names may be different from kit to kit. As always, you can find the correct name to use for each family in the Kit Editor. Select a font family on the right, and then click “Using fonts in CSS” to open a dialog with the font-family name and some examples. Use the handy copy CSS button to quickly copy and paste the font-family name into your CSS.

Getting information on font-family names in the Kit Editor.

If you’re using the API to create kits, you’ll continue to get the old style with two font-family names by default, so that existing API applications that expect this behavior don’t break. If you’d like to create a new kit with the new font-family name style using the API, you can use the newly added segmented_font_family_names parameter.

Fewer weights and styles enabled by default

We’ve also changed which weights and styles are enabled by default when you add a new font family to your kit. We used to enable all available weights and styles when adding families, which could result in a large number of enabled fonts. Unchecking them all was a chore, and many users didn’t change the default and published kits that were unnecessarily large.

Starting today, when you add a family to a kit via the Typekit website, only a default set of up to four weights and styles will be enabled. This default set contains the fonts in the family that map most closely to the normal and italic styles in both 400 (normal) and 700 (bold) weights. This corresponds to the fonts from the family that a web browser would select when using font-style: normal or italic and font-weight: normal or bold in CSS. This gives most users the weights and styles they expect while keeping kit sizes smaller by default. As always, you can check additional weights and styles in the Kit Editor to include them in your kit.

Only four basic weights and styles are enabled by default when adding a font family to a kit.

If you’re using the API, you’ll continue to get all available weights and styles by default when adding a font family to a kit. You can always select specific weights and styles with the variations parameter.

If you have any questions about these changes, don’t hesitate to drop a line to support@typekit.com.

You’ve long been able to add Typekit fonts to your WordPress.com blog, but that service just got a whole lot better. Starting today, a new Custom Design upgrade provides a visual font preview that allows you to modify your theme quickly and effortlessly — no coding required. Just pick some fonts and instantly see how they will look on your blog.

We worked closely with WordPress.com on this new tool, incorporating feedback from users to make it as easy to use as possible. You can quickly change the fonts for your site title, headings, and body text, and preview how they will look on your site before committing. And you can now edit the size and style of those fonts, an oft-requested feature. Most importantly, you can do this all from within your WordPress.com dashboard — no need to bounce back and forth between WordPress.com and Typekit. Plus, the new Custom Design upgrade supports all themes: if you’ve been waiting to add Typekit to your blog because your theme wasn’t supported, that wait is now over.

Sound exciting? It is. And here’s a quick screencast so you can see it in action:

Typekit + WordPress.com

►

If you are already using Typekit on your WordPress.com blog, we encourage you to upgrade to get all these new features. But you need not do so: you are free to continue using your current Typekit account for as long as you like. Also, for those of you who prefer to edit your own CSS, you can switch to the “advanced mode” in the Custom Design upgrade and use a Kit ID from your Typekit account. Read more about how to use the advanced mode.

If you have any questions about the new Custom Design upgrade, head on over to WordPress.com to learn more.

Update: We now offer an official asynchronous embed code through the Kit Editor, so you no longer have to create your own. Details are available in this blog post.

The standard Typekit embed code has many advantages. It’s simple, compact, very easy to implement, and automatically helps to prevent the flash of unstyled text (or FOUT). These advantages make it the right choice for the vast majority of sites.

The asynchronous loading patterns that we’ll discuss in this post provide a useful alternative in situations where you must eliminate any possibility that a problem loading the kit could interfere with loading the rest of the page. Asynchronous patterns are longer, more difficult to implement, and require extra work to avoid the FOUT. But these approaches ensure that your page won’t wait for the kit in the unlikely event that something goes wrong somewhere between the font network and the user.

In fact, we use the font events asynchronous pattern described below on the Typekit status blog to ensure that our users can reliably read about our system status, even during a font network outage or degradation.

Standard Typekit embed code

Before discussing asynchronous loading patterns, let’s take a detailed look at what happens when using the standard Typekit embed code. This will help to frame the differences between the standard embed code and asynchronous patterns.

When a web browser parses and renders a web page, a <script> tag will block the rendering of elements and the execution of scripts further down the page. This is because web browsers use a single-threaded model when executing JavaScript. The script that’s executing could use document.write() to alter the page, or trigger a redirect to go to a different page entirely. Because the browser doesn’t know what executing the script will do, it waits until the script is done loading and executing before moving on. Modern browsers continue downloading other resources on the page while the script is executing, while older browsers put a hold on that too.

Typekit’s standard embed code is just a simple pair of <script> tags. The first is an external <script> tag that loads the kit JavaScript from our content delivery network (or CDN). The second <script> tag is a piece of inline JavaScript that actually kicks off font loading using the kit.

<script type="text/javascript" src="//use.typekit.net/abc1def.js"></script>
<script type="text/javascript">try{Typekit.load();}catch(e){}</script>

This standard embed code takes advantage of the fact that <script> tags block further rendering of the page to help prevent the FOUT. While the Typekit script is loading, rendering of the page is blocked, so text won’t start to render with fallback fonts. Once the script has finished loading and executing, the FOUT can be controlled with font events, as we’ve discussed in a previous post.

Normally, this works great, but the downside of this approach becomes apparent in the rare event that the Typekit script takes too long to load. What was once a desirable delay in rendering to hide the FOUT becomes a serious problem when the script takes longer than a few seconds to load. The page will fail to render as long as the request for the kit fails to return a response. We labor tirelessly to make sure that this never happens, working with our CDN partner to ensure that kits are delivered in a reliable and timely manner around the world. Unfortunately, it’s impossible to forsee and prevent every outage, network problem, and user configuration issue.

If this failure mode, however unlikely, is an unacceptable risk for your project, you should consider using one of the following asynchronous patterns instead. Asynchronous patterns don’t block rendering of the page while the fonts load, which means that the FOUT must be dealt with via other means.

Standard asynchronous pattern

This first pattern is the most basic. It’s based on patterns written about by web performance experts like Steve Souders and used in other JavaScript embed codes like Google Analytics.

<script type="text/javascript">
  (function() {
    var config = {
      kitId: 'abc1def'
    };
    var d = false;
    var tk = document.createElement('script');
    tk.src = '//use.typekit.net/' + config.kitId + '.js';
    tk.type = 'text/javascript';
    tk.async = 'true';
    tk.onload = tk.onreadystatechange = function() {
      var rs = this.readyState;
      if (d || rs && rs != 'complete' && rs != 'loaded') return;
      d = true;
      try { Typekit.load(config); } catch (e) {}
    };
    var s = document.getElementsByTagName('script')[0];
    s.parentNode.insertBefore(tk, s);
  })();
</script>

This pattern uses a single inline <script> tag to dynamically add a new script element to the page, which loads the kit without blocking further rendering. An event listener is attached that calls Typekit.load() once the script has finished loading.

How to use it:

• Place this snippet at the top of the <head> so the download starts as soon as possible.
• Edit the highlighted config object and replace the default with your own Kit ID.
• You can add JavaScript font event callbacks to the config object.

Advantages:

• Loads the kit asynchronously (doesn’t block further page rendering while it loads).

Disadvantages:

• Adds more bytes to your html page than the standard Typekit embed code.
• Causes an initial FOUT in all browsers that can’t be controlled or hidden with font events.

Font events asynchronous pattern

When using the standard asynchronous pattern, the inability to hide the initial FOUT with font events while the kit JavaScript loads is a serious drawback that might be a dealbreaker. This next pattern builds on the standard pattern, but adds the ability to control the initial FOUT with font events.

<script type="text/javascript">
  (function() {
    var config = {
      kitId: 'abc1def',
      scriptTimeout: 3000
    };
    var h = document.getElementsByTagName('html')[0];
    h.className += ' wf-loading';
    var t = setTimeout(function() {
      h.className = h.className.replace(/(\s|^)wf-loading(\s|$)/g, ' ');
      h.className += ' wf-inactive';
    }, config.scriptTimeout);
    var d = false;
    var tk = document.createElement('script');
    tk.src = '//use.typekit.net/' + config.kitId + '.js';
    tk.type = 'text/javascript';
    tk.async = 'true';
    tk.onload = tk.onreadystatechange = function() {
      var rs = this.readyState;
      if (d || rs && rs != 'complete' && rs != 'loaded') return;
      d = true;
      clearTimeout(t);
      try { Typekit.load(config); } catch (e) {}
    };
    var s = document.getElementsByTagName('script')[0];
    s.parentNode.insertBefore(tk, s);
  })();
</script>

This pattern uses the same basic approach as the standard pattern, but adds additional JavaScript that provides basic font event CSS class name support before the kit has even loaded. When the script first executes, the wf-loading font event class name is immediately added to the <html> element. After a configurable timeout, if the script hasn’t yet loaded, wf-loading is replaced with wf-inactive. When the fonts finish loading, wf-inactive will be replaced with wf-active. You can use these class names to hide the initial FOUT by setting visibility: hidden on elements with Typekit fonts while the wf-loading class name is present. For example:

#page-title {
  font-family: proxima-nova-1, proxima-nova-2, sans-serif;
}
.wf-loading #page-title {
  visibility: hidden;
}

How to use it

• Place this snippet at the top of the <head> so the download starts as soon as possible.
• Edit the highlighted config object and replace the default with your own Kit ID.
• Edit the highlighted config object to adjust the number of milliseconds to wait before switching from wf-loading to wf-inactive while loading the script.
• You can add JavaScript font event callbacks to the config object.

Advantages

• Loads the kit asynchronously (doesn’t block further page rendering while it loads).
• Provides font events that allow you to control the initial FOUT while the script loads.

Disadvantages

• Adds more bytes to your html page than both the standard Typekit embed code and the standard asynchronous pattern.
• Requires writing additional CSS to hide the initial FOUT in all browsers (as opposed to the standard Typekit embed code, where FOUT is hidden automatically in all but Firefox).

Other patterns

The two patterns discussed above represent the best options we’ve found for loading Typekit fonts asynchronously. We’ve explored a few other patterns as well, but won’t go into detail on them here. They have additional drawbacks and compatibility issues, but they might be useful in certain circumstances.

Standard and font events asynchronous patterns with jQuery

If you’re already using jQuery on your page, you can use jQuery to shorten the amount of JavaScript necessary for both the standard and font event asynchronous patterns discussed above. This reduces the size of your HTML page, but also delays the loading of the Typekit script until the jQuery script can be downloaded, parsed, and executed. You can see the standard jQuery pattern and font events jQuery pattern on GitHub.

Embed code at the bottom of the page

You can prevent the standard Typekit embed code from blocking the initial rendering of your page by placing it at the bottom of the <body> tag instead of in the <head>. While this allows your page to render, it delays the loading of the Typekit script until the entire page is nearly finished parsing. In addition, there’s no way to control the initial FOUT, and this pattern may still block the execution of other JavaScript on the page. You can see the bottom of the body pattern on GitHub.

Script tag with async attribute

Modern browsers allow you to add an async attribute to a <script> tag, which tells the browser to load the script asynchronously and not block the rest of the page. However, older browsers, including IE 6-8, do not support this attribute, nor do they support onload on <script> tags. (The similar defer attribute, which is often used instead of async in older versions of IE, isn’t a good option here because it delays execution of the script until parsing of the page is complete.) The lack of support for this method makes it less useful. You can see the async attribute pattern on GitHub.

On GitHub

All of the async patterns mentioned in this post are available on GitHub as example pages in the typekit-async-patterns repository. You can head over there to see them all together, download the examples and try them out, or even fork the repository and add your own patterns if you’d like to contribute.

Typekit has long been the trusted web font provider for some of the biggest sites on the web. We first served fonts for The New York Times back in December of 2009, for example, and since then the list of high traffic sites and services using Typekit has grown to include examples from across the spectrum: The New Yorker, The Wall Street Journal, Martha Stewart, Gizmodo, Twitter, Zynga, Ning, Atlantic Records, WordPress, and more. Businesses like these rightly expect a web font solution that’s ultra-fast, always online, and includes the kind of customer support that ensures fonts render beautifully and dependably, every time. We’re honored to have delivered on those needs.

Today, we’ve added a new class of subscription plans that make it even easier for customers to take advantage of the benefits Typekit has to offer larger sites. Now, sites with traffic of up to 25 million pageviews per month can simply sign up for a monthly business subscription plan via our website – no complicated contracts required. In keeping with the needs of high traffic sites, all of these new plans include an uptime guarantee and VIP support, so you can rest assured that you’ll get the same worry-free service that our largest customers already enjoy. And all of this comes without a long term commitment: these plans are billed monthly, and you’re free to upgrade, downgrade, or cancel at any time. We have plans for sites of all sizes. Check out our business plans page for details.

Like all of our subscription plans, these new plans give you access to world class fonts from the best foundries, optimized for the web and continually updated as browser support and font technology evolve. Simply put, we’re committed to providing you the easiest, highest quality, most future proof web font solution available so that you can benefit from all the value of web fonts while continuing to focus on what you do best – running your business.

Need more than 25 million pageviews, custom fonts, or CDN integration? No problem! Just contact us, and we’ll put together a custom Enterprise Plan to meet your needs.

We’ve just launched the new Typekit status blog, where you can go for up-to-the-minute reports on the status of Typekit’s services. Visit it at http://status.typekit.com and be sure to bookmark it for future reference.

The status blog shows the current and recent status of all three distinct Typekit services: the font network (which serves fonts to your websites), the Typekit website (where you manage your kits), and the Typekit API (used to programmatically manage kits and fetch font metadata). Each system operates independently; e.g., the Typekit website could be down for maintenance, while the font network remains up and continues to serve fonts to your websites.

As the font network is our most critical service, its current status is highlighted across the top of the site; while the status of all three services is noted in the sidebar. Additional details (when they exist) will appear on each day of an event. The status updates are color-coded (green for ok, yellow for experiencing trouble, and red for down), so you can quickly assess the health of the whole system.

The status blog represents the culmination of emergency planning from the entire Typekit team. We care deeply about the performance of all of our services, and work hard to keep everything running smoothly. But we also think it’s prudent to plan for the worst case scenarios, however unlikely they may be. And as part of that planning, it’s important that we be able to communicate promptly and transparently. The status blog affords us the space to do that; and moreover, it’s a public reminder of our obligation to do so.

Subscribe to the status feed to stay up-to-date.

Typekit is proud to be a sponsor of Letter.2, the second international competition of typeface design organized by AtypI. Letter.2 aims to promote typographic excellence and to raise awareness of the role of typography in encouraging and maintaining cultural diversity. The jury features renowned type designers and typographers, including Peter Biľak, Rubén Fontana, John Hudson, Akira Kobayashi, Lucie Lacava, Gerry Leonidas, Fiona Ross, and José Scaglione.

All typefaces produced between October 2001 and August 2011 may be submitted. Submissions are due by August 15th; best of luck to all the entrants!

Tim Brown, Typekit’s Type Manager, interviews Tim Ahrens, founder of Just Another Foundry and type designer at Typekit, on designing fonts for the web, changing business models, and more.

Illustration by Olimpia Zagnoli

Tim B: Hi Tim. Introduce yourself!

Tim A: Originally an architect, I moved towards type design and font production in recent years. I did research on optical sizes and developed software that makes type design easier and quicker. Currently, I live in London, where I run Just Another Foundry.

Tim B: At Just Another Foundry, you provide web licenses for your fonts and even host files for your customers. Why did you decide to offer your typefaces on Typekit, too?

Tim A: Most desktop fonts are being sold by several distributors — even the big players offer each other’s fonts. I am expecting a similar development for web fonts; foundries want to reach as wide an audience as possible.

However, with web fonts, we are encountering new opportunities and challenges we didn’t know about before.

Foundries have been thinking about font renting and pay-per-use for quite a while, but in the world of desktop fonts, monitoring usage wasn’t technically possible. With web fonts as a service, we can price fonts more appropriately depending on the scale of our customers’ projects. We can offer low-budget options without spoiling the professional market. In this context, Typekit’s subscription model is very interesting — as a customer, you don’t have to tie yourself to a specific font, but the foundries still get their share according to actual use. I think that’s ideal.

On the other hand, web fonts confront us with technical challenges. This new technology is not as easy to set up as it first seems, and I’m not expecting it to become very straightforward soon. Typekit does a great job at figuring out all the details and providing the infrastructure, and I’m convinced you wouldn’t find that level of expertise anywhere else.

Tim B: The forthcoming W3C web standard for web font files, WOFF, should eventually simplify @font-face definition syntax because different browsers won’t need to use different font files. It should also make managing physical files easier for web designers who decide not to use a web font service. Won’t that make things more straightforward? What other technical challenges do web fonts present?

Tim A: WOFF is a good development. Once the majority of browsers support it, it will make things easier for everyone since we will only have to deal with a single, compact file per style. For foundries, it makes it much easier to create fonts that are standards-compliant but cannot simply be pulled off the web and installed on a computer. In that sense, it provides some protection from font theft.

However, WOFF only provides a useful barrier between the web and the desktop world. What will happen when fonts for web use become the main market and people hardly care about installing fonts anymore? Then illegal spreading of fonts will be easier than ever, even without the active passing on by those who purchased them — anyone can download someone else’s WOFFs and use them on their own website.

This is where web fonts as a service come into play. If a certain typeface is simply not available for self-hosting then anyone who does so is doing it illegally — and in public. That is probably enough to deter most people. And this is why at Just Another Foundry, except for major clients, we will probably stick to offering our fonts exclusively as a service or via other services, even if self-hosting becomes technologically very simple. Ultimately, we need to balance user needs with the interests of the foundries, and some of these decisions will not be driven by technology. The good news is that if offering web fonts as a service helps us keep down illegal font use, then users win because we can offer professional fonts at a much lower price.

Tim B: When we talk about typefaces, we often refer to the designs as a whole: Helvetica, Myriad, FacitWeb. But when you say there’s one WOFF file per style, that means a separate font file for each style of a font (Regular, Italic, Bold, Bold Italic, etc.). Some families also have small caps, OpenType features, and alternate widths (condensed, extended). What’s involved in organizing a typeface, with all of these constituent parts?

Tim A: When OpenType was introduced about ten years ago it brought some major improvements: unlike in previous formats, the fonts are cross-platform compatible. Even TrueType and PostScript were unified, using a similar wrapper. Furthermore, the new format allows us to include a very large number of glyphs for many languages in one font. Finally, unlike before, typographic extras such as small caps, ligatures, or oldstyle figures can be accessed through smart layout features instead of having to handle them in several fonts.

Unfortunately, now, just when we thought producing and using sophisticated typefaces had become simple, web fonts throw us back into pre-OpenType times. We need to provide several formats to cover all browsers and platforms. In terms of advanced glyph sets, most browsers support only a few OpenType features, if any at all. And I doubt that support will expand very soon; consider that MS Word still does not support small caps ten years into OpenType. Another issue is that fonts can potentially contain malicious code. Understandably, browsers put safety first and disable OpenType features by default (as in Firefox) or even remove anything in the font that smells of executable code (as it is done by the “OpenType Sanitizer” built into Chrome).

We can include and reliably use any character that has an official Unicode value — accented characters, non-latin scripts, arrows, and soon even cherries and bananas — but most of the typographically advanced features are not available in all browsers even if they exist in the font. Small caps and oldstyle figures are considered graphic variants, not characters with a distinct semantic meaning, so they don’t have Unicode indices.

For some features such as ligatures, contextual alternates, or kerning, web designers might accept that they are not applied in all browsers and welcome them where available. Other typographic variations, such as small caps, are too distinct and meaningful to be left to chance. For now, all we can do in order to use them is to bite the bullet and go back to putting these glyphs into separate fonts, even though this is not as convenient and elegant as selecting an option in the layout application. However, fonts on the web are not used in the same way as in desktop applications, and if many typographic choices are made through the interface of the web font service anyway, then there is a chance that these kinds of technical workarounds will be barely noticeable to the user.

Apart from the UI implementation, the task of splitting up fonts to make the typographic extras available is more challenging than one might expect. Today, fonts are designed and produced with OpenType features in mind, so dissecting and rearranging their inner parts is difficult to automate. In my collaboration with Typekit, we are currently working on this so that users can get the most out of the typefaces.

Tim B: You mentioned that many of today’s web browsers are incapable of handling font features properly, and that one way around this would be to offer designers the ability to make typographic choices through a web font service interface. What responsibilities would a service undertake in offering such an interface, in terms of keeping up with proper web standards and keeping an eye on browsers as they evolve?

Tim A: Web fonts are a great opportunity to implement typographically sophisticated websites in a transparent way that lets search engines or screen readers access the plain text and the structuring thereof. We must be careful not to tamper with this when we try to make non-Unicode glyphs available. It is very tempting to put special ligatures or alternate glyphs onto rarely used character positions in order to make them available, or to use private-use Unicode values for accessing small caps, for example. However, although it would look fine in the browser, this would make the text “unreadable” for robots, it would give you flawed plain text when copying from a website, and display incorrectly where web fonts are not supported.

So, keeping the underlying text strictly semantic is the key virtue, and for that it looks like we will have to use separate fonts, at least under the hood. The devil will be in the details, however. Are small caps semantically to be treated as lowercase? What if someone prefers to use them without a capital letter at the beginning? Should this be treated as semantically all-caps, or should only the first letter be encoded as uppercase? In any case, it will require a well-thought-out user interface.

It seems that the development of font and web technology will never stop. Once one problem is solved and everything seems to be easy, the next challenge comes up. People will always want something better and smarter — and rightly so! — and so we, the type specialists, will have to keep working out how to make it possible, and easy to use.

Tim Ahrens is a type designer and architect who runs the London-based studio Just Another Foundry and works for Typekit. He designed FacitWeb specifically for screen display.