EJS logo

Tomorrow’s web type today: The fine flourish of the ligature

In preparation for my talks at TYPO Berlin next week and Ampersand next month, I’m brushing up on a load of future-facing techniques to do with typography on the web. I’m calling this series of posts ‘tomorrow’s web type today’ and I’m using each post’s heading to demonstrate a particular technique. Oh, and you may have noticed that in order to accomplish this, I’ve redesigned my site… again!

First up, I want to talk about ligatures. Like most OpenType features, we’ve wanted ligatures on the web for ages. In addition to looking a bit fancy, the primary purpose of the ligature is to make text that little bit more readable by avoiding awkward clashes, like the terminal of an f with a dot on an i. If you look at the title of the post above, you should see ligatures for fi, fl, and the slightly less common Th. If not, here’s how the type should look:

Note the fi, fl, and Th ligatures. And yes, in case you’re wondering, this post’s title was intentionally written to be ligature-tastic.

In the body text you’re reading now, you should also see ligatures present (more on that in a second). Of course, whether you see them or not does depend on your browser, so let’s get to the first important question:

What is browser support like?

The good news is that browser support is far wider than you might think: the latest versions of Chrome, Safari, and Firefox all support ligatures. That’s on a Mac. On Windows, Chrome and Safari support is good, but in my tests via Browserstack, I couldn’t see support from Firefox or IE, even though they’re meant to be on board. (Note to self: more testing required.) But by and large, we’re surprisingly well covered. I would encourage you to start adding support for ligatures today. Like all future-facing web development, you’ll be better placed when the other browsers catch up.

But how?

This is the really interesting part. Most people use text-rendering:optimizeLegibility; to turn on ligatures (which also turns on kerning, and is on by default on Firefox and Chrome), but for more control — and, some might argue, more robust future-proofing — take a look at the working draft of the CSS3 Fonts Module (EDIT, 18.05.2012: new link) and, specifically, the font-variant-ligatures; property: the proposed methodology should allow us to turn on common ligatures and discretionary ligatures using font-variant-ligatures:common-ligatures discretionary-ligatures; (EDIT, 18.05.2012: new value). Unfortunately support is currently theoretical, but don’t fret because we can achieve the same using the more widely supported font-feature-settings property. Here’s a line from my site’s CSS file:

body { 
    -moz-font-feature-settings:"liga=1, dlig=1"; 
    -moz-font-feature-settings:"liga", "dlig"; /* EDIT: new syntax for FF 15+ */ 
    -ms-font-feature-settings:"liga", "dlig"; 
    -o-font-feature-settings:"liga", "dlig"; 
    -webkit-font-feature-settings:"liga", "dlig"; 
    font-feature-settings:"liga", "dlig";

Make no mistake: font-feature-settings is a god-send. I like it because it conforms to standard OpenType conventions, but more importantly we can use it to turn on other OpenType features we usually only see in desktop design apps, such as swashes, stylistic alternates, and small caps… but I’ll save them for another post in this series. For now, you might be interested in Mozilla’s handy reference page. And John Daggett wrote about this way back in 2010, which shows how slow adoption has been. The downside is that some browsers (such as Safari) currently still require text-rendering:optimizeLegibility; to turn on ligatures.

All fonts are not created equal

Even if you enable ligatures for your site, their display is of course dependent on the font file containing ligatures. Some fonts do, some don’t. Some have the basics, some have every kind of ligature you can imagine. And even if you’re sure that a typeface has ligatures, many web fonts save file size by omitting them from the font file. For instance, with Typekit you’ll need to export ‘all characters’ in your kit settings, and sadly that does mean your font files will be considerably bigger.

Also, as I said before when I was redesigning Smashing Magazine, it’s important to remember that files differ between font delivery services. At the time of writing, Typekit’s version of Skolar doesn’t contain ligatures, but Fontdeck’s does, which is why I’m serving the body type for this site through Fontdeck.

For a bit of indulgence, here are a few of Skolar’s ligatures you should be seeing throughout this body text:

ff fi fl ffi ffl

Skolar actually has many more ligatures (see the PDF specimen) and I must admit I’m not sure why I’m not seeing the rest, especially with discretionary ligatures turned on. Perhaps they’re not included in this particular font file? Suggestion welcome.

Expert subsets

I mentioned small caps above, but that really does deserve its own post, as we get into a wider discussion about how that’s being handled by solutions such as Fontdeck’s ‘expert subsets’ — font files that contain only limited characters, used for special circumstances, such as for small caps. That will be next in the series!

I hope this has been useful. I’m always happy to be corrected, so if you’ve spotted anything amiss in this article, please let me know via the comments. Massive thanks to Rich Rutter, whose An Event Apart talk helped shape this post and the others that are on the way.

Heading: Adobe Caslon Pro, served via Typekit. Body: Skolar, served via Fontdeck