Web typography: where we are today

TL;DR & Disclaimer

I am not a web designer myself, in that web design is not my main skill nor what I do for a living. However, as a web developer, whereas I may sometimes struggle to choose two colors that fit well together, I am very interested in web design nevertheless and I often do need to take into consideration more technical aspects design practices that may impact on performance or the SEO value of a site or web application and even security, in some cases, as we’ll see later. One thing I am also interested in is web typography.

I have been recently researching and testing old and new techniques to embed custom fonts in web pages, and found the topic quite interesting from the aforementioned points of view as well as usability; so I thought I’d put my notes together in a post with pros and cons for each technique; as a result, the post is purposely long, since I wanted to create a sort of up-to-date reference on the subject, for myself as well as for others who may (hopefully) find it useful; I believe it could help save a lot of time to many new to the subject or who are looking for updates, vs reading a few years worth of articles, hacks, bugs and techniques… many of which are by now outdated and no longer working.

Introduction

When you design an piece of art, an advertisement, but also a website, all you want through your design is communicate a feeling or, more generally, an idea. You want your idea to attract and persuade as many people as possible, but -equally important- you also want your idea to reach the target audience unaltered, or the reactions may differ from what you expected.

So also when you are in the process of designing a new website, perhaps the biggest concern you have -together with general usability- is that the site should look the same to all users as it looks to you, and as you want it to look. Therefore, since people use different web browsers, your site must be as cross browser compatible as possible, look and behave the same way at least in A grade browsers. The task isn’t always easy, since some browsers tend to follow standards more than others, but with a little patience and a number of tricks even the most complex of designs can tweaked for cross browser compatibility.

Web typography

One very important aspect of web design (as important as in any other form of design) that, however, hasn’t required too much effort towards this goal for quite some time now, is typography; all the most popular operating systems have shared for years a set of commons fonts, thus also known (in the context of web typography) as web-safe fonts; among these, the popular Arial, Helvetica, and others. Because these fonts are available on most systems, as long as a web page uses any of these fonts, there is the guarantee that the page will look the same (at least with regard to fonts, that is) for most, if not all, users (does anybody still use Lynx, by chance?)

This simplicity, however, comes with a price, in that the number of web safe fonts available to choose from is pretty small, limiting the possibilities for a creative designer who would like her pages to stand out but also cares about SEO, for example, and therefore would prefer using regular text over graphics whenever this is possible without compromising a winning design concept.

Luckily, these days we do not have to use always the same, boring, web-safe fonts. There are a number of techniques that can be used to circumvent this limitation and let us embed (almost) any fonts in our pages, to our liking, although each of these techniques also has its own drawbacks which should be carefully taken into consideration.

A quick look at web typography’s history

(If you are not interested in how techniques for web typography have evolved over the time, you can just skip to the next sections and read about pros, cons, and practical workarounds for each technique.) In the very beginning of web browsers’ history, there wasn’t a way to define which fonts a browser had to use to render a web page, with the result that each browser would render the page with whichever fonts that were available on the system, and according to its own settings. The ability for web designers to specify themselves, in advance, which fonts should be used, came when Netscape introduced the font tag (now deprecated) in HTML2 (1995). Thanks to this tag, a designer had for the first time the freedom to specify any font, at least in theory. In reality, for this to work those fonts had to be already installed on the same computer as the browser; if that wasn’t the case for a user, some other fallback fonts would be used instead, often with very different results. So there was no guarantee that the page would actually look the same for all users, nor that it would look as intended by the designer.

CSS2 (1998) introduced some rules for font synthesis, matching and alignment, that designers could use to define which characteristics alternative fonts should have in order to be selected, if the primary choice of font was not available. But these rules were basically ignored by most designers since they required a big deal of technical knowledge about fonts, making these rules quite difficult to adopt in most cases, and in fact they didn’t last long, having then been removed from the CSS2.1 (2005) specifications.

One good thing though that CSS2 had introduced and that was surprisingly removed, as well, in CSS2.1, was the possibility to define that a font, if not already available on a user’s system, could be downloaded and used for the rendering instead of some fallback fonts, with the @font-face rule. Despite this rule had been removed from CSS v2.1, Internet Explorer 4 added support for the @font-face font downloading, although it required the use of the proprietary Embedded OpenType (EOT) format, with the result that IE remained for a while the only browser to support this feature; you also had to use a tool by Microsoft to convert any TrueType font to EOT for use in web pages.

That was until CSS3 (in development since 2005) reintroduced the support for @font-face in its specifications, and Safari 3.1 (2008) made it possible to use any licensed TrueType or OpenType font in web pages. These two events lead to other browsers also supporting the font downloading and saw an increasing interest in web typography, with a number of different techniques being developed to use custom fonts, all with their own pros and cons.

In the following sections of this post, we’ll have a look at each technique available today (at least to the best of my knowledge – if you know of more, worthy of attention, please let me know in the comments!), with benefits and downsides.

Image replacement

Perhaps the most obvious technique to circumvent the limited choice of web-safe fonts without too much effort, involves displaying images containing text (since you can use whichever fonts in images), rather than regular text. I have never liked it, but I think it’s worth mentioning why, since still today I see tons of sites using, and abusing, this technique.

It works well for graphics that do not contain just text – well, you don’t have much choice in this cases, do you? – but it’s not a brilliant idea if all you want is to render some text with a non web-safe font. Also, for headlines or any other portions of text that you may have to display on multiple pages but with different text, this technique is not very practical, since you would have to create a different image for each portion of text (unless you automate this process in some way). So, generally, speaking:

benefits

• it’s very easy; all you need is create an image with the font you like, for each portion of text;
• images look identical across browsers almost always;

downsides

• it’s not a good idea to just replace text with images from a SEO perspective; images are not accessible by search engines which, in fact, ignore them. At most, search engines will use the information in the alt attribute, if present (although this information is more useful for image specific search), but this won’t be the case if CSS is used to place the image on a page, for example as background for some element. It is possible to have an acceptable compromise by having both regular text -accessible by search engines- and an image that contains the same text and is displayed, via CSS, on the top of that text. This makes the text more visually appealing thanks to the image as well as helping search engines access that information. But you should be careful here, in that depending on how this is done, search engines may actually think all you are trying to do is [keyword stuffing]9http://en.wikipedia.org/wiki/Keyword_stuffing) (or just “spam”, if you prefer), thus penalising your site instead (see Google’s Matt Cutts‘ notes in a blog post on the subject some time ago);
• hidden text as per the previous hint may not be accessible by screen readers, depending on whether you hide the regular text with display:none or visibility:hidden; this issue can be limited by not using either of them and by setting the height of the element containing the regular text to 0, or tweaking the text indentation so that it ends up somewhere outside of the visible screen space, but.. still..we’re not done with the downsides; I must confess here that I don’t spend myself much time on these issues, although I obviously should and would if I could invest more time on them; but it’s worth mentioning these accessibility issues anyway for the sake of completeness;
• users cannot select nor copy text from images to the clipboard (which is something a lot of people do all the time when surfing the Internet);
• users cannot find text in the page with the browser’s find functionality, since it’s hidden (unless.. you look at the source);
• users won’t be able to increase the font size for improved readability;
• users won’t be able to change the color, or contrast of the text, again for improved readability;-
• if for whatever reason a user’s browser has images disabled, that user won’t see any text at all since images won’t be loaded and the regular text is hidden with CSS; well, luckily this happens rarely, but… you should keep this in mind too;
• images require as many HTTP requests plus as many other requests as the different fonts used, therefore if you use this techniques with more than one custom font and more than one portion of text on the same page, and perhaps with non optimised images, all this could significantly impact on performance. You could optimise images (for example with tools such as Yahoo’s Smush.it and reduce the number of HTTP requests by using CSS sprites (with tools such as CSS Sprite Generator), but unless you find a clever way to automate all this process across pages.. I don’t think it’s a great idea.

This technique involving images is generally known as Fahrner Image Replacement (or FIR), although it appears that this technique was actually first introduced by Douglas Bowman in 2003.

The Flash variant

There’s a variant to using images in place of regular text, that uses Flash instead of plain images. Since it uses Flash, text can be resized without affecting the quality of the rendering, therefore this technique is commonly known as Scalable Inman Flash Replacement (or sIFR).

This variant is more flexible than the original one in that…

benefits

• it does not require the creation of as many images as the portions of texts that should be rendered with a non web-safe font;
• it only requires a Flash element instead, and some JavaScript code to dynamically change the text contained in that element, for each portion of regular text to replace;
• text can be selected, and copied to the clipboard;
• improved general accessibility vs plain images variant;

However…

• both Flash and JavaScript must be enabled for the user to be able to read that text, although this technique is usually used in a way that fails back to traditional rendering when either Flash or JavaScript or both are not available;
• Flash is heavy on CPU.. I am sure Steve Jobs would bomb Adobe each time he sees a website abusing Flash even just for text!
• Flash files, JavaScript, CSS to render the text still require multiple HTTP requests, affecting performance even more;
• many users love browser extensions that block Flash ads. The thing is, these extensions also block text rendered with this technique!

The Facelift variant

Yet another variant, called Facelift, is quite similar to the previous one but uses yet again plain base images, in place of Flash, to dynamically generate the actual images that will render the text. However it requires server side processing with PHP and has reduced accessibility, compared to the Flash variant.

A similar one -I think, since I haven’t tried it- is PHP + CSS Dynamic Text Replacement (or PCDTR), which also requires PHP as is affected by the same limitations.

Other techniques

Over the years other solutions have been developed that address some of the shortcomings I’ve mentioned for the previous ones, and use neither images or Flash to render custom fonts, but JavaScript with some other technology that depends on the browser.

A popular one among these is Cufón. Developed by Finnish Simo Kinnunen, it’s based on JavaScript but does not require Flash; instead it uses either VML in Internet Explorer, or the canvas element in other browsers that support HTML5 in order to render web fonts. It’s faster than the Flash alternative, but once again, users cannot select and copy text.

Then there is Typeface.js, which is quite similar but allows the selection of text at the cost of lower performance.

All these techniques are IMHO just ugly hacks more than anything else, and I have never liked them for the (many) reasons listed. As said I am not a designer but a developer, so I may be missing (again, please let me know if I am) cases when, or reasons why, any of these may instead be good options, but since I am a developer I tend to look at things from other perspectives as well, non just at how good a page looks.

Luckily, there are better alternatives, with better support from web standards, so.. read on.

Embedding fonts with the @font-face CSS rule

Now that we’ve had a quick look at why the previous techniques aren’t really great, let’s go back to the @font-face rule available once again with CSS3, as this is -IMHO- the best one since there’s an increasing support by browsers and standards, and while it still requires some hacks, these won’t be required for long, I think. Plus, since it involves using regular text, no SEO hacks are required and the accessibility of the text is fully preserved.

As briefly mentioned earlier, the @font-face rule allows a browser to download a font required for the consistent rendering of a page, if that font is not already available on the system, so that the site can look as the designer intended, for all users with browsers that support this feature:

@font-face {
font-family: "the font's name";
src: url("/fonts/font-file");
}

Using one of these fonts isn’t any different from using any web-safe font:

.a-css-class {
font-family: "the font's name";
}

The src descriptor optionally accepts the format of the font file to download, so to ensure the correct usage of the font:

@font-face {
font-family: "the font's name";
src: url("/fonts/font.otf") format("opentype");
}

Supported format definitions are “truetype” (.ttf), “opentype” (.ttf, .otf), “truetype-aat” (“TrueType with Apple Advanced Typography extensions”, also .ttf), “embedded-opentype” (.eot), and “svg” (SVG font, .svg).

To improve cross browser compatibility, it is also possible to specify multiple files and formats at once, so that -at least in theory, as we’ll see- each browser can just select the format it best supports:

@font-face {
font-family: "the font's name";
src: url("/fonts/font.eot") format("embedded-opentype");
src: url("/fonts/font.otf") format("opentype");
}

I’ve seen some people using conditional comments in CSS and similar, uglier hacks to provide cross browser definitions of font faces… Luckily as we’ve just seen we can avoid this, since the @font-face rule itself allows for multiple locations and formats for our fonts.

@font-face: compatibility and issues

Despite we can define multiple font locations and formats in a single @font-face rule, however, there’s a couple of known issues with Internet Explorer that need to be addressed. The first is that IE actually does not recognise the format descriptor, and therefore thinks that the remaining part of the rule is a continuation of the file name, resulting in IE attempting to make a bad request to a file which doesn’t exist. The second is that it doesn’t just stop at the first font file if it is a .eot (thus supported) font, as you would expect. It will instead download each font file within a src: url() descriptor, or at least attempt to (because of the format issue).

Various solutions have been developed to overcome these issues, leading to the combination of the following “rules”:

• the IE font declaration (.eot) should come first, and should not have the format descriptor;
• fonts for other browsers should use format with the src: local() descriptor instead, since local is not recognised by Internet Explorer;
• also, for the other browsers, rather than having multiple src descriptors we can use a single one which defines at once multiple locations and formats; this way each browser will stop at a supported format and download that file, ignoring the rest;

Translated into CSS code:

@font-face {
font-family: "the font's name";
src: url("/fonts/font.eot");
src: local("the font's name"),
url("/fonts/font.woff") format("woff"),
url("/fonts/font.ttf") format("truetype"),
url("/fonts/font.svg") format("svg");
}

This syntax ensures that Internet Explorer only downloads the .eot file without even trying to download the others, while other browsers will correctly select whichever font they support.

A problem though with this syntax, as also explained in Paul Irish’s post (2009), is that local implies that if a font by the same name already exists on the user’s system, that font will be used instead. This can improve performance for those users since they do not need to download the font, but what would happen if the local font isn’ the same as the font the designer meant to embed in the page? Until recently, the commonly accepted fix for this was to prevent the browser from matching a local font by name. This can be done, for example, by using an unlikely name for the font in the src: local() descriptor, rather than the actual name.

A common choice has been for a while the smiley character… the reason being that two-byte unicode characters, at least according to the OpenType specifications, should not be used in font names:

@font-face {
font-family: "the font's name";
src: url("/fonts/font.eot");src: local(""),
url("/fonts/font.woff") format("woff"),
url("/fonts/font.ttf") format("truetype"),
url("/fonts/font.svg") format("svg");
}

So, is this the ultimate cross browser syntax for font embedding? Well.. it was.. until very recently. Since all these hacks and techniques first appeared, there’s been a lot of changes, most notably more and more people have started to use smartphones a lot to surf the Internet, adding mobile browsers to the mix..

Ethan Dunham, of web fonts provider Fontspring found just a few days ago that our beloved smiley breaks font loading on Android phones. So the new syntax he recommends as a consequence is the following:

@font-face {
font-family: 'MyFontFamily';
src: url('myfont-webfont.eot?') format('eot'),
url('myfont-webfont.woff') format('woff'),
url('myfont-webfont.ttf') format('truetype'),
url('myfont-webfont.svg#svgFontName') format('svg');
}

Apparently, using a single src descriptor and appending the ? to the name of the .eot file, solves both the aforementioned issues with Internet Explorer, without requiring the smiley hack and thus improving compatibility with Android devices too; it also solves the problem with the local descriptor since it is no longer required.

The trick here is that the ? makes the rest of whole rule look like a querystring appended to the .eot file name for Internet Explorer versions < 9, so these versions of IE will happily ignore that whole part completely, and only download -correctly- the .eot font; IE 9, instead, will skip the eot format and use the woff instead.

A side benefit of this updated syntax is that it looks cleaner, and less “hacky”; according to Fontspring, this newer syntax boosts a better than ever compatibility, working just fine with the following browsers and devices:

• Safari 5.03
• IE 6-9
• Firefox 3.6-4
• Chrome 8
• iOS 3.2-4.2
• Android 2.2-2.3
• Opera 11

I think that, generally speaking, people who use other browsers than IE tend to keep their browsers up to date more frequently, so considering this, and that this technique even works with older versions of IE, this solution looks pretty rock solid at the moment.

Flash of unstyled text (FOUT) issues and workarounds

A common issue with font embedding, which remains even with the latest recommended CSS syntax, is that some browsers, by design, currently render text before external fonts are downloaded, using some fallback font. This translates into an unpleasant flicker effect when the browser re-renders the text once the custom font has been downloaded and is ready to use.

Both iOS and Android devices are affected, but also the latest stable version of Firefox at the moment of this writing (3.6). The longer it takes for the browser to download these fonts, the less visually appealing this side-effect is. Eventually all browsers will address this, but in the meantime some hacks are required – yet again – for a better cross browser compatibility.

Paul Irish’s 2009 post also explains the issue and shows some possible solutions, from hiding the entire page until the fonts have been downloaded and the text rendered, to hiding only the text which uses non web-safe fonts, temporarily.

Both may be risky depending on the implementation if JavaScript (which is required to hide and then show the text) is switched off, however the latter -temporarily hiding only the affected text- seems to be the way Webkit browsers handle this issue natively. This works quite well in Safari and Chrome, but it is possible to emulate this behaviour in other browsers with JavaScript.

As Paul suggests, the easiest way to accomplish this is to use the WebFont Loader, a JavaScript library developed by Google and Typekit which is now part of Google Font API.

The correct, basic syntax, as suggested in Paul’s post is the following:

<script src="//ajax.googleapis.com/ajax/libs/webfont/1/webfont.js"></script>
<script>
WebFont.load({
custom: {
families: ['Tagesschrift'],
urls : ['http://paulirish.com/tagesschrift.css']
}
});
</script>

At the same time, you should use the CSS classes .wf-loading, .wf-active, and .wf-inactive for the font loader to work. I’ll borrow again a snippet from Paul:

/* we want Tagesschrift to apply to all h2's */
.wf-loading h2 {
visibility: hidden;
}

.wf-active h2, .wf-inactive h2 {
visibility: visible;
font-family: 'Tagesschrift', 'Georgia', serif;
}

This syntax still works and solves the issues when JavaScript is disabled, in that text for the H2 tags (as per Paul’s example) is only hidden (before the user may notice it) if JavaScript is enabled, then it is made visible again and rendered as soon as the web font is available; if JavaScript is disabled instead, the text may look uglier, but at least is visible and rendered with a default font.

The font loader also supports execution of custom code on events, so for example you can easily fade text in while it has been rendered with the web font, and more. Have a look at the documentation for more details.

Another library you may optionally want to have a look at is Webfont Load Enhancer by Michael van Laar, which addresses rendering issues when font smoothing is turned off and could also be used in conjunction with Google’s library since it’s pretty small.

So, does this font loader just work?

Well… more or less. There are a few issues that should be taken into consideration when using this technique:

• If for some reason the download of the font takes too long or fails entirely, users won’t see any text… A possible fix for this is to make the affected text visible, regardless of whether the font has been downloaded or not, after a limit amount of time, say 2-3 seconds. For example, if you use jQuery:

$(function() {
setTimeout( function() {
$("h2").css("visibility", "visible");
}, 2500);
});

• According to Google, major browsers are supported, but only the latest versions of iOS and Android are supported for mobile devices.
• For the WebFont API to work properly -while also circumventing the FOUT issue with Firefox and others- the script has to be added to the HEAD section of the page, or anyway before the text to render. But the call to the WebFont.load() method also requires the API file to be downloaded first – in a synchronous and, more importantly, blocking way, potentially affecting the overall rendering performance of the entire page.

I’d like to add another tip which I haven’t seen mentioned anywhere with regards to using Google Web Font Loader. In the example above, we see that the standard syntax involves specify in the JavaScript settings the URL of the stylesheet to download and that contains the @font-face rules. However, during my testing I noticed that to yield the best results, it’s a lot better to include these rules in a page with a link to the same stylesheet but separately, before everything else, so that those CSS styles, together with the fonts, get downloaded a bit earlier. So Paul’s example would become:

<link href="http://paulirish.com/tagesschrift.css" rel="stylesheet" type="text/css" />
<script src="//ajax.googleapis.com/ajax/libs/webfont/1/webfont.js"></script>
<script>
WebFont.load({
custom: {
families: ['Tagesschrift']
}
});
</script>

During my testing, I could really see that this helps a lot to remove the FOUT issue, so I am pretty surprised that it’s something you won’t find mentioned in most other articles and posts on the subject.

Should we use this hack for all browsers against FOUT?

As previously mentioned, all recent browsers based on Webkit already implement a similar technique to hide text and render it as soon as the font has been downloaded.

IE doesn’t seem to be affected, and as for other popular browsers, one thing that I’ve noticed while reading posts here and there on the FOUT issue, is that almost everybody mentions Firefox, but almost nobody mentions Opera. Perhaps it is because a lot more people use Firefox than they use Opera, but unless there’s something wrong with my Opera install, I am pretty sure I’ve seen exactly the same FOUT-related behaviour in both Firefox and Opera.

Therefore I’d like to suggest another little change to the syntax we’ve already seen, to only use Google’s web font loader for Firefox and Opera, while ignoring it for the other browsers:

if ( (typeof navigator.oscpu !== 'undefined')
|| (typeof window.opera !== 'undefined') ) {
WebFont.load({
custom: {
families: ['font name']
}
});
}

The trick above works well and it’s lightweight since it uses native methods to check whether the browser is either Firefox or Opera, without requiring libraries such as jQuery or more complex browser detection with JavaScript. In fact, navigator.oscpu is only available in Mozilla’s browsers, while window.opera, well… is only available in Opera.

The reason I suggest to only use the font loader with Firefox and Opera is that I’ve seen a noticeably faster rendering in the other browsers (which do not need it anyway) without it.

Performance

Of course, embedding non web-safe fonts in your web pages means that the browser will have to make as many HTTP requests as the fonts to download, plus another request for the font loader script, and a number of different DNS lookups depending on the number of different domain names involved. All these can and do affect performance depending on how many resources to download, but also on how optimised the fonts are, and on how they are served with regards to caching, HTTP compression, connections management, and more.

Apart from this, in the last code snippet of the previous section we’ve seen how to let Firefox and Opera use Google’s font loader, while other browsers handle web fonts natively, which as said -I think- makes the rendering faster for those browsers; I haven’t really done any benchmarks on this, but this is what I’ve noticed during my testing.

However these browsers will still make an HTTP request for the font loader script even though they are not using it. If your site is completely dynamic by choice or because it has to be, you may add functionality that detects the browser server side and excludes the relevant script tag from the page unless the browser is Opera or Firefox.

If your site, instead, caches content to static pages for improved performance, then you don’t have much choice. You can either leave that HTTP request regardless of the browser, or detect the browser client side and, only for Firefox and Opera, load the script in blocking way (so that the it is loaded before the WebFont.load() call) with the ugly document.write:

if ( (typeof navigator.oscpu !== 'undefined')
|| (typeof window.opera !== 'undefined') ) {
document.write(unescape("%3Cscript
src='http://ajax.googleapis.com/ajax/libs/webfont/1/webfont.js'
type='text/javascript'%3E%3C/script%3E"));

WebFont.load({
custom: {
families: ['font name']
}
});
}

I haven’t actually tried this since I hate document.write, but it should work, the same way it usually works with those lovely ads that load in a blocking way slowing down most web pages…

If you could load the API script asynchronously, you could also decide on the client whether to load the script or not depending on the browser, for generally better performance (non blocking loading for Firefox and Opera, and one less HTTP request for the other browsers) – but because the script is required before the WebFont.load() call to fix the FOUT issue, this is not possible, unfortunately.

Another thing about HTTP requests worth mentioning, is that web fonts can also take advantage from direct embedding in a CSS stylesheet thanks to the data URI scheme.

This scheme allows you to eliminate the separate HTTP request otherwise needed to download a web font, by adding the font data, encoded in base64 text, directly to the stylesheet:

@font-face {
font-family: "font name";
src: url("data:font/opentype;base64,[base64-encoded font data]");
}

Sounds great, doesn’t it? The problem is that ideally font files should not be too large for this technique to work well, otherwise the weight of the stylesheet may grow quite a bit since base64 encoding tends to increase the size of a file. However it’s a great way to reduce HTTP requests so you should also take this into consideration, since more HTTP requests are generally more expensive and the stylesheets, even those including encoded font data, can greatly benefit from caching, if caching is handled properly.

It is important anyway to also keep in mind the limitation with the file size in browsers (IE for example supports data uris up to 32KB.. no more), and that some browsers, including versions of IE prior to the 8, do not support this feature at all.

Security

By default, Firefox only allows downloading fonts from the same domain as the page that embeds them. The reason for this is that otherwise anybody could freely use fonts from other websites, and as we know there are often licensing issues with many fonts.

Because of this, if a website is expected to allow the downloading of its fonts from within the context of other websites and domains, that website should make use of access control headers to make this possible. This is something you should remember if you want to use your own fonts across websites, rather than using a font provider.

This is not the only security related issue that concerns web fonts. You should also be aware that it has been suggested a number of times that web fonts may, under some conditions, make for a possible vector of attacks, especially when fonts are loaded from a third party domain. What would happen if, for example, a font provider were hacked and, say, fonts were compromised? Could compromised fonts be used to exploit vulnerability in browsers?

Well, the answers is definitely yes since something similar, actually, has already happened, with Firefox.

This vulnerability didn’t affect Firefox users who were also using the popular NoScript extension by Giorgio Maone, since the extension by default already blocks web fonts, for the same reason that other embeddable, external resources are normally blocked. In that particular case, blocking web fonts resulted in those Firefox installs not being vulnerable, so since this may happen again in the future, there is reason to believe this feature will stay there and that perhaps other security tools may also follow suit.

So, if you are planning to use third party’s web fonts in our sites, you should take into consideration both potential vulnerabilities and users who may not be able to see text when both JavaScript and @font-face are disabled by extensions like NoScript.

Unfortunately, improved security often comes with a price.

Can we use web fonts in HTML emails?

Most email clients by default block images for security reasons, so it would be nice if we could also prettify HTML emails circumventing this limitation, by using web fonts and CSS instead. Unfortunately, only Apple Mail and iOS devices will render web fonts in emails.

So the answer is no, at the moment it would not work.

Web fonts providers

As we’ve seen, it is important that fonts are optimised for download (with HTTP compression et al) as well as for caching to minimise the impact on performance. While you could use your own fonts, you would be better off using a provider that already hosts a wide range of fonts available either for free or that offers a paid service. Most of these providers also use CDNs to improve deliverability of their fonts to users around the world.

The most popular free service clearly is Google. It offers a nice (and growing) selections of fonts available for free, and also offers the loading mechanism I’ve mentioned earlier, which helps solve FOUT, among other issues.

Using a good font provider helps with performance also in that fonts are usually highly optimised for the purpose, but also thanks to potentially better caching. The more websites use these providers, in fact, the more chances there are that a user’s browser may already have in cache the fonts your site requires, thus avoiding the need for that user’s browser to download the same fonts. This obviously translates in faster rendering of the page, minimising the aforementioned issues with Firefox and other browsers because of FOUT.

Other known font providers, apart from Fontspring and Typekit which I have already mentioned are:

• http://www.fontfont.com/
• http://www.ascenderfonts.com/ (link no longer active)
• http://fontdeck.com/ (link no longer active)

But as said there is a growing interest in web typography so there are already many other providers to choose from.

Protected fonts and licensing

If at this point despite some hacks and potential issues you haven’t changed your mind, are still planning on using web fonts in your sites and perhaps thinking that you could embed any fonts into your web pages, I am afraid you’ll be a little disappointed to read that this is not strictly true. While many fonts are free, many others are not and have some license that should respected, and that often can also be quite costly.

You will also notice, if you try to optimise for usage with web pages some fonts taken for example from your operating system, using a tool like Fontsquirrel @font-face generator, that you will be forbidden to do so.

This is because font providers and this kind of tools use blacklists to avoid issues with known fonts that require licensing for use with a website, such as the fonts available with some operating systems.

So, in general, it is important that you only use fonts that you are allowed to use.

Conclusions

We’ve seen a number of techniques which make it possible to embed custom fonts in web pages, so that we don’t have to use always the same, boring web safe fonts we see everyday on almost every website.

We’ve also seen why it is better to leave some of these techniques alone, and why instead the @font-face CSS rule, while still requiring a few hacks (for now), clearly is the best option for custom web font embedding available today.

Should you use it?

This depends a lot on your site, what you want to achieve with it, and also what your audience is. If the vast majority of your audience uses devices compatible with @font-face, and you don’t care too much about that tiny fraction of your user base who may purposely limit their browser experience in favour of improved (although sometimes exaggerated) security, and implement font embedding keeping in mind performance, then the answer is -IMHO- a resounding yes.