Aloe Studios

A List Apart recently published an article by Håkon Wium Lie titled CSS @ Ten: The Next Big Thing. In this article, Håkon discusses a potential future method of loading fonts via css from specified URLs.

The css goes something like this:
@font-face { font-family: "Kimberley";
src: url(http://www.princexml.com/fonts/larabie/kimberle.ttf) format("truetype");
}
h1 { font-family: "Kimberley", sans-serif }

And there you have “web fonts.” Pretty simple. Pretty cool. The (potential) problems are security and legality. Security because who knows what might happen to any one of the multiple web font URLs you might be linking to. And legality because potentially any schmuck with a web server could post pirated fonts.

My Recommendation

As much as I’m in favor of web fonts, I can see that the problems of security and legality are pretty serious. So what I recommend is a centralized Web Font Server and some sort of committee or consortium to oversee which fonts get included in the Web Font Library.

This is a level of bureaucracy and centralization that I’m sure some won’t be comfortable with, but I see it as a very viable alternative to the current recommendation. The committee would have the final say as to what fonts are included and could also make recommendations on minimum font sizes for more decorative fonts.

I’d like to see a system where font designers could submit their fonts for inclusion in the library, and the public (as well as the committee) could be involved in the selection process. Perhaps some whiz could even whip up some software that could detect suspected knock-offs of licensed non-free fonts.

Off course, this is a utopian vision. There’s no doubt in my mind that the committee could bottleneck with their selection process. And there will be scores of mad-at-the-world cry babies when their font submissions are rejected for inclusion to the web font library. You’ll always have the folks who think allowing more fonts is a bad idea (Comic Sans, anyone?). And of course getting some browser manufacturers (IE) on board may be challenging.

I also wonder if centralizing the web fonts might mean less code in the css. At first I thought that it could be as simple as no change to the code, and just a change in the browser’s handling of the css whereby fonts are searched for on the local machine first, and then on the web font server if necessary. In theory this could still work, but it leaves open the potential for lots of calls back to the web font server if the css is sloppy.

Next I thought that perhaps all fonts on the web font server could have something specific in their filenames such as pre-pending “WFL_” (for Web Font Library) to the front of the filename. But that is a slippery slope, as some goofballs will inevitably distribute fonts with those names and install them via a virus/worm etcetera (these virus fonts would inevitably have all kinds of inappropriate imagery in them). So perhaps they could be denoted in a different way - maybe with something as simple as adding brackets around the names or just using a character not permitted in filenames.

Maybe simply { font-family: [WFL:fontname], fontname; } … Perhaps it’s best decided by people smarter than me!

I don’t know anything about browser programming, but I can’t imagine it would be too difficult to add this functionality to a browser with a minor update.

So that’s my recommendation to the W3C or anyone who will listen. If you like my idea, hate my idea, or have your own idea - I encourage you to post a comment on the original A List Apart article: CSS @ Ten: The Next Big Thing. If you don’t feel like signing up for A List Apart then leave a comment here (but if you read this, then you really should be signed up at A List Apart!)