Webkit is super smart with unicode-range. It’ll only download the ampersand font if you use an ampersand. Because it gives the browser advance knowledge of the usable chars in the font, webkit will download fonts in parallel rather than series.

Regarding unicode range and subsets: At Fontdeck we have tiny fonts we call ‘expert subsets’ containing only OpenType features like swashes for some faces like Pimlico and Trilogy. Firefox 4 supports CSS 3 OpenType features. For the rest, specific characters can be displayed using OpenType alternates, swashes, or anything else, using regular HTML hooks. However, this is better way if the fine folks at Mozilla can implement it.

Rich Rutter has described subsets as a modular approach. I agree, and refer to them already as modular font stacks. Including special features in small files that can progressively enhance the type, perhaps selected with this method, makes a lot of sense for those of us concerned with performance and extensibility.

We are using Eigerdals (through Fontdeck) for the heading typeface, which I adore, but I have never been keen on the ampersand, it looked a little too much like a ligature for Et. So using the technique you demonstrated I have switched to Hoefler Text just for the ampersands.

However, I see one big flaw with this: how are you to style the ampersand itself? For example, you may want the ampersand to be italic, it may have a different x-height so needs a different font-size and so on and so forth.

I discovered that the ampersands I wanted to use were all in the italic font and naturally I wanted my titles not to be. So I used the ‘PostScript Name’ of the individual font style I wanted to use rather than the family, and this worked.

I deliberately only have fallbacks that looked as I wanted them, because if it cant find one of those it falls back to Eigerdals. For Firefox I gave the @font-face rule the same fallback stack as I had for the title text originally.

I’m a little confused by your write-up here, the behavior you describe is different from your example. In your example the @font-face rule containing ‘local(Arial)’ follows the one containing ‘local(Baskerville)’. This renders the same in Firefox 8, Safari 5, Chrome 17 and IE9, it always uses Arial. The behavior you describe (Firefox showing Baskerville) actually occurs if you use the reverse order than the one shown in your example. Here’s a testpage showing the variations.

The unicode-range descriptor is really intended to help better control load behavior for subsetted fonts designed to support a wide variety of scripts and languages. Especially for CJK fonts, these can be rather large. An author can include a set of subsetted fonts to support Japanese and via unicode-range assure that those fonts are only downloaded when Japanese characters are actually used on the page.

If the unicode ranges overlap for a set of @font-face rules with the same family and style descriptor values, the rules are ordered in the reverse order they were defined; the last rule defined is the first to be checked for a given character.

So the last @font-face rule defined is the first one matched. The reason this is specified this way is so that an @font-face rule defined later can override a specific range. If the compounding worked the other way, a given @font-face rule that didn’t specify a unicode-range descriptor couldn’t be overriden by later rules.

This isn’t a case of Firefox not wanting to implement this feature, we’ve just been focused on better support for the rich typographic controls that are also part of CSS3 Fonts. Just a matter of priorities, we have every intention of implementing all features described in the spec.

As for “opentype” vs. “truetype” format hints, the spec defines them to be synonymous. That’s due to the fact that the terms are used ambiguously and OpenType is a superset of TrueType.

Have you checked that this issue is logged as a bug in bugzilla? Given that this is a quite a niche use (at least at present), it’s not unlikely that the Firefox developers aren’t even aware of this issue.

Also, you say that “the font shouldn’t be downloaded if none of the characters within the Unicode range are present in a given page.” Is that the actual behaviour, or is that just the expected behaviour?

Would an alternative fallback be to strip down the font (using, say, FontForge) so that it only includes the characters to be substituted? I understand that some fonts’ licensing and distribution methods preclude this, but for other fonts, it could potentially mean less fallback CSS and smaller font downloads.

Awww :3 There we are again. Great to have you here on the worlds most brilliant advent calendar.

Very interesting article, as ever.
Used @fontface a lot and never knew unicode-range existed. Thank you!

How do I declare multiple characters?
unicode-range: character, character, character; ?
A new fontface rule for every special character seems a bit dull, especially, when they’re nested in the same font ö.ö

I’ve seen folks using the icon fonts like Dingbats etc for stylish bullets and so forth and I gather you could use this Unicode trick to allow you to use various dingbats from various font faces.

One question about the implementation of the code. Does just loading a certain range of unicode characters lower the download from the entire font library? say you ref Mrs Eaves as a font-face but only want the ‘& does using this unicode statement limit the download to just the & character or is the whole Mrs. Eaves font downloaded and only the one character is rendered?

I have seen in the case of Google Fonts where you can just link to a smaller font file if you are going use certain characters and not the whole alphabet.

Very interesting article, I might use this. Just to be a nitpicker though, in the first CSS example you gave, the file extension was .ttf, however you gave it a format of opentype (rather than truetype). However, great thoughts, and really looking forward to the rest of the 24 ways this year :)

With regards to the notion some people are passing round that Firefox is the new IE. This is utterly bonkers. None of the modern browsers being released now are “the new IE”. Not even IE.

At the rate FF releases are going it won’t be too long before unicode-range support lands. Not to mention for the time being font rendering is much better in FF than any other browsers (at least on windows) in terms of legibility and kerning which I think are more important than subsetting.

Compared to FF, IE9 has no text-shadow, flexbox, gradients, transitions, webworkers… the list goes on, but that doesn’t mean it’s a bad browser.

Couldn’t you use a unicode range that excluded the ampersand with Arial, and list that before your ampersand font.

In theory, you could. That would mean scoping a range above and below the characters you wanted to exclude. Browsers don’t currently support multiple ranges properly, so each range would need its own @font-face rule to do so.

It works, but you end up with much more complex and hard to maintain rules.

Why not just use javascript to find all “&” and replace them with <span class=“ampersand”>&</span>?

Nice, but you end up mixing and matching fonts inline. Of course that’s still better than a height:1em PNG. But what I’d really like to see is a true fallback for missing glyphs.

Say I want to use the emoji characters and provide an emoji webfont for that range, but once the general font has native emoji glyphs, use those because they were designed to fit in with other text in that font.

Now the only way to achieve that is to measure the rendered characters in Javascript and guess if they are present in the font or just a placeholder. Or use webfonts for everything (because I know the range of the fonts I provide), but that’s a big overhead.

The one caveat is that you need to use Postscript names, not fullnames (i.e. “Futura-MediumItalic” instead of “Futura Medium Italic”). If you’re using an OSX machine, open Fontbook, select a specific font, then select Preview > Show Font Info. Both the Postscript name and fullname are shown.

Very interesting post to start with this year.
It is always regretful when a browser as popular as firefox doesn’t support it.
In the past IE had the most problems, but recently it becomes more and more firefox.