In terms of design (and (designed) information hierarchy) it might be a little old school, even intimidating, but if you’re a typographer on the web, Tal Leming and Erik van Blokland’s .webfont Proposal is well worth reading. As Leming puts it:
We’re hopeful that this is a good format for everyone. It gives users smaller file sizes. It gives the font vendors a simple format that allows them to include information about the font. It doesn’t require entirely new technologies from the browser developers.
With the current interest surrounding Typekit and yesterday’s announcement by David Berlow of Font Bureau of a proposal for a Permissions Table for OpenType, the issue of typography on the web is, thankfully, appearing to reach a tipping point (not before time).
Leming and van Blokland’s proposal is interesting for a number of reasons. Firstly, it appears to have the backing of a sizable number of the world’s leading type foundries. In barely a week it has attracted support from, amongst others, FontFont, H&FJ, Emigre, House Industries and Process Type Foundry. Those are some impressive names and, as Typegirl puts it (with just a hint of wit), “With this much weight behind it, it has to be taken seriously.”
Secondly, its approach to the issue of what to display when encountering a potential license issue is encouraging. Rather than refusing to display the typeface intended and fall back on another specified typeface, the browser renders the page with the typeface, but displays a simple, unobtrusive alert about the discrepancies in the font’s domain information.
Philosophically this embraces a Digital Rights Assistance (DRA) approach as opposed to a Digital Rights Management (DRM) approach and is consequently less likely to alienate end users.
So, what exactly is the proposal?
A Little Deciphering
To save you filtering through 500+ messages at the W3C mailing list (and to spare you from some of the more esoteric discussion) we’ve listed some of the key posts below. Brace yourself, however, the language can - at times - be less than user friendly.
So, in plain language, what exactly does this proposal mean?
If we’re interpreting it correctly (and feel free to comment if you think we’re not), what this means is as follows. A typeface in Leming and van Blokland’s proposed .webfont format consists of a compressed file containing two files with the following names:
The first file,
info.xml, contains information about the font including meta data supplied by the foundries. Critically it contains an
<allow> field which contains a list of URLs allowed to use the font (for open source fonts, this could be set to ‘any’, allowing the font to be used on all domains). This allows a font to be licensed for a specific domain. The second file,
fontdata, contains the actual font file.
Authors can specify a font using
@fontface in CSS, referencing a .webfont uploaded to the web site’s relevant directory. Simple. (And legal.)
What’s appealing about this proposal is its reliance on an existing standard -
@fontface - that removes the need for workarounds and hosted solutions (one of the key criticisms of the Typekit proposal).
The Tipping Point
Once again we find ourselves moving quickly in a debate about the future of web standards and the tools we use as web designers and developers to design for the web (witness the recent XHTML DOA WTF debate). It’s encouraging, however, to see that the issue of typography on the web appears to have reached a tipping point, with a huge amount of talent now addressing the issue.
Tim Brown’s recent experiments with open source typefaces, licensed for use on the web - Glyphs of Steel and All Aboard - showcase the potential of well-crafted type coupled with
@fontface. When the major foundries sign up to a proposal and it’s completed, designers will enjoy the many benefits.
Leming and van Blokland’s proposal looks, alongside a number of other recently announced proposals, to point in the right direction. We can only hope the issue is resolved, sooner rather than later.