Elliot Jay Stocks is a designer, speaker, and author. He is the Creative Director of Adobe Typekit, co-founder of lifestyle magazine Lagom, founder of typography magazine 8 Faces, and an electronic musician.

Tomorrow’s web type today: from Qaegkvwyz to Qaegkvwyz using stylesets

Posted on 15 May 2012 Comments

It pains me to say it, but this is the first post in the ‘tomorrow’s web type today’ series that doesn’t look best in a WebKit browser: this time around, it’s Firefox’s turn to take the limelight. EDIT: Thanks to commenters below, I’m getting reports of this working in the latest Chrome on Windows and the most recent Safari Beta on Mac. It may sound a little hypocritical of me, given that the reason I used subsets for the heading on yesterday’s post was because I thought Firefox-only support wasn’t enough, but I couldn’t do a hack two days in a row.

So, if you haven’t done so already, I urge you to open Firefox (EDIT: or the latest Chrome on Windows) and look at this post there. I personally feel that Firefox’s text rendering is relatively poor — I don’t like the way it calculates em squares and, in turn, renders line-height and padding (look at the moz-specific rules I’ve had to employ in this post’s stylesheet) — but it’s currently the only browser to accurately render OpenType stylesets; in this case, those contained in the wonderful Bree.

If you’ve been following along with this series (if not, check out my posts on ligatures, small caps and old style numerals, and swashes), I’m sure you’ll know by now that this is the point in the post where I show you the screengrab of how the heading type is meant to look:

Screenshot
The second ‘Qaegkvwyz’ line accesses Bree’s stylistic alternates to give a more formal feel to the type.

Invoking the styleset is achieved like so:

h2 span.word8 { 
-moz-font-feature-settings:"ss01=1";
-moz-font-feature-settings:"ss01" 1; /* For FF 15+ */
-ms-font-feature-settings:"ss01" 1;
-o-font-feature-settings:"ss01" 1;
-webkit-font-feature-settings:"ss01" 1;
font-feature-settings:"ss01" 1;
}

As I said in the intro, sadly it’s currently only Firefox (EDIT: and the latest Chrome on Windows) that supports stylesets, but it’s good to have some future-proof code in there, eh? Speaking of which, note the syntax change for the forthcoming Firefox 15.

The future

Eventually, in the far-flung future when font-variant-alternates is implemented, we’ll have more robust tools (like robots and spaceships!). There are even plans in the spec for rules that decide what to do when a styleset isn’t available. Here’s the example Rich used in the AEA talk I keep I referencing:

@font-feature-values Bree Web { 
    @styleset swashlike 1;
}
h2 {
    font-family:"Bree Web", sans-serif; 
    font-variant-alternates:styleset(swashlike);
}

We’re a long way off that, though, so let’s not worry too much. For now, we can stick to font-feature-settings and hope for better browser support in the near future. And, as suggested by the pattern emerging in this series, you can add wider support today by using a subset. Fontdeck even provide an Expert Subset for Bree, exclusively containing its stylistic alternates. I could’ve used this to get the heading above working in browsers other than Firefox, but I figured it’s good to eat your own dog food every now and then.

A summary of using OpenType features with CSS today

I haven’t covered everything in these first four posts — other features include proportional versus tabular numerals, fractions, historical forms, etc. — but by now you’ll see that using OpenType on the web today essentially comes down to these key considerations:

  • Consider the typeface: does the actual typeface contain swashes, ligatures, and the like?
  • Consider the font file: is it actually an OpenType file being served? Even if it is, are the extra glyphs you need included in that particular font? Do you need to adjust any settings to export additional characters?
  • Consider the browser: which features does it support? Remember: support can differ massively between version numbers and operating systems. Do you need to ‘polyfill’ support by adding special characters via subsets?
  • Consider the user: will the design break if certain OpenType features are missing? Does the type actually look that good? Even generous feature support is subject to poor type rendering on some operating systems. No names mentioned.

Next up, I’ll be moving away from OpenType to cover some more ‘down to earth’ features such as hyphenation. Phew!

Heading: Bree, served via Fontdeck. Body: Skolar, served via Fontdeck

© 2005 – 2014 Elliot Jay Stocks. All rights reserved. Powered by Siteleaf and tracked by Gaug.es. To keep updated with new content, you might like to subscribe to my RSS feed.