CSSquirrel A look at web development and web design by Kyle Weems

I’ve been meaning to mention this for a while now, and have been noticing a few blog posts on the topic recently, so I think I’ll add in my voice. If you haven’t check out Cufon yet, go do so. And yes, I know the “o” is supposed to have an accent mark over it, but I’m not going to put the effort into that other than this post’s title.

What is Cufon? Cufon is a plugin-free, Javascript-powered alternative to rich font embedding. In particular, it’s a great alternative to flash-powered sIFR, which prior to Cufon was the best way to get rich font support during our long desert of poor font-embedding support that is the modern web.

By “great alternative”, I mean that it “lights sIFR on fire, kicks it into an open sewer, and laughs maniacally as sIFR rolls around in stinky, burning pain.”

Yes, it’s that much better. And if you don’t agree, I’ll punch you.

Ok, that’s not true. I’m opposed to violence. I also never learned how to throw a punch, and I’m worried that I’d break my thumb.

However, it is better. For three major reasons. 1. It doesn’t require you to own Flash to build the font file you’ll be using. 2. It doesn’t require a plugin in your browser to work (aka, it works on iPhones among other things). Lastly, 3. It’s way, way faster.

It’s things like Cufon that convince me that in the near future that Javascript will be the new Flash. (canvas and SVG make my pants tight in an embarrassing way.)

How does Cufon work? Simple.

1. Visit their site. Download the cufon script. Include that in the head of your page.

2. Get a font, and using their nifty generator, turn it into a .js file. (Supports several standards, including OTF and TTF.) Link that font script in the head of your page after the cufon script.

3. Do an air guitar riff. (Optional.)

4. In a script you add, include a  command to the effect of Cufon.replace(“elem”) where elem is the element you want the font to replace. If you’re only using one font with Cufon, it’s as easy as that. If you’re using multiple fonts, you’ll need to do Cufon.replace(“elem”, “font name”), where “font name” is the name of the font you want that element to use for that element.

5. Look on in awe as the font are replaced so fast, your page will go slightly back in time.

An example of a finished result is right here. It’s simple, but it gets the point across.

Like sIFR, I can’t recommend using the font replacement on large fields of text. Selecting the text for copy/paste purposes is difficult (although not impossible), and it’s bound to have an impact on performance if you use it too widely. But selectively used it can open your projects open to a cornucopia of fonts (licenses allowing.)

What are you waiting for? Go get it now!

On Monday I made a post over on the Mindfly blog about the travesty that is Microsoft continuing to go their own way when it comes to web standards. In particular, it appears that rather than following the standards in the CSS3 Web Fonts Module in IE8, they’re instead going to continue to push forward with EOT, their proprietary embedded font format that they’re just now beginning to open up.

And surprise, they’re expecting the rest of the Internet to follow their lead.

I’m not going to repeat in detail the rant I made on the Mindfly blog, but I can’t help but feel that despite security issues related to font embedding that Microsoft is going about things the wrong way. Does font embedding need to be secure so font makers aren’t screwed? Yes. Does Microsoft need to decide for the rest of the world what that method is? No! Whatever happened to embracing standards?

I’m curious about other people’s views on the subject. Is Microsoft’s version of @font-face (and it’s insistence upon EOT fonts) a better path than the W3C’s version of @font-face (as currently seen in Safari)? Is security a good excuse to ignore standards?

Yesterday I wrote a post at Mindfly describing how to make use of the CSS @font-face rule for embedding fonts into web pages. I figured it was timely, as I’m getting tired of the number of times I have to use an image (or putz around with workarounds like sIFR) to substitute a special header all because of a non-web safe font, or a client with very specific typographic tastes and a very poor understanding of how the web and fonts work together (or more to the point, how they don’t). Furthermore, both Firefox and Opera have intentions to add support to the feature very soon, creating a world where all four major browsers will have the function (although with IE using EOT and not TTF it won’t be all peace and happiness quite yet).

The thing is, the more I look into the topic, the more it appears that @font-face won’t going to be ushering in a Utopian society of pretty fonts. The core issue seems to be how legal is font embedding going to be, and how will typographers feel about developers putting their font files on servers in a place where they could potentially be snatched?

So far the answers seem to be ‘not very’ and ‘not good’, respectively.

Which makes me wonder, what good, if any, will @font-face actually serve us. If, as a solution, it creates only another problem, a legal problem, that standards themselves can’t fix, is it worth the effort investing into this path to web fonts? Perhaps browser people should be looking into another technique that’ll prove to be more secure for the font files. Something that won’t look good on paper but results in a lot of angry mail from lawyers.

Although, it does make me wonder. Is there a technique that could be used with the current @font-face rule that would still protect the fonts?

@font-face. Good? Bad?