-
Earlier this week it was announced that WebKit now supports CSS @font-face rules. I’m not sure how long it will be before we see this in Safari – many months probably – but it is almost inevitable. And when I say support, it’s not the limited, proprietary support we’ve seen since IE4, but full support for TrueType files (I’m guessing this also implies TrueType-flavoured OpenType files).
There has been a mixed reception in some quarters, but I agree with Dan and Jon in that this leap forward (for that’s what it is) has to be a good thing. sIFR is great – a fabulously clever and effective hack – but it’s always just been a patch waiting for the proper fix which is @font-face. Sure, some web designers will end up using shockingly inappropriate fonts, but others will enhance our experience will carefully chosen, superior typefaces. I don’t care. It’s just great to think that this stuff may start to be possible.
We should also remember that outside of Latin fonts, good work is going on by organisations such as the Greek Font Society whose fonts are among the best available for Greek. For many minority langauges, good fonts are simply not widely available at all, so web fonts would go a long way to helping this situation.
Regarding Latin fonts, John Gruber put it to Typographica that “the fonts you’re allowed to embed legally aren’t worth using; the fonts that are worth using aren’t embeddable”. That’s mostly true, but not entirely. As I reported in June, font publisher Ascender already provides a server licence for its fonts, which include all of Microsoft’s fonts along with a few others (including Bembo, Sabon and Perpetua). The point being that Ascender’s server license has been available for 4 months and by the time @font-face actually makes it into Safari (and probably Opera) other font publishers may well have followed suit. I certainly hope so.
Of course this does lead us to the concerns highlighted in a Typophile thread wherein many folk are concerned about the implications of openly linking to TrueType files on servers, and the effect it will have on font publishers and foundries. The lesson here is that now – right now – is the time for font publishers to accept that @font-face is something designers really need, and have wanted to do for the last 9 years. Sticking heads in the sand is not going to make it go away, so if they want a different solution, font publishers need to start talking to browser manufacturers straight away.
It is certainly possible to work out a technical implementation that gives designers and their customers what they need, while still protecting the intellectual property of the font houses. One suggestion might be to limit @font-face to fonts on the same server as the web page would go a long to helping the situation, either by building this into the browser or the font itself. Alternatively we could keep things completely open, as currently implemented in the WebKit build; it’s quite possible this wouldn’t affect the font foundries in the slightest – getting hold of pirated fonts is already easy, and yet there are plenty of design agencies, corporations and clients who continue to pay for legitimate copies.
Whatever the upshot of this, I repeat that the introduction of @font-face to Webkit and eventually Safari has to be a good thing. Sure Safari only has 5% overall market share, but Internet Explorer 7 still supports @font-face for .eot files, so given Microsoft’s association with Ascender, we may well see a TrueType-enabled @font-face feature in Internet Explorer 8. As for Firefox, we may have to wait a year or so as @font-face is not scheduled for Firefox 3.
