sIFR & Olly

Posted by matt on Fri, Jan 9, 2009 at 3:42pm

For those who might be curious, the fancy-looking KnockOut headlines that now accompany featured articles on the front page are being rendered using a terrific JavaScript/Flash-based plug-in called sIFR (Scalable Inman Flash Replacement).

For a long time, typography on the web has been bad. Bad, as in: severely limited. Here's the problem. HTML tells your web browser what text to render, and gives it some guidelines on how to render that text, but your web browser can only render text using fonts on your own computer. Sure, you can plop the name of any font into an HTML tag or a CSS font-family: declaration, and if you have that font installed on your computer, it might just work. HOWEVER, if another user doesn't have FancyPants CurliCue Font™ (or whatever) on their computer, they'll probably see nothing more than good old Times New Roman.

Here's the crux of the problem: you can only expect any given computer to have a pretty paltry handful of fonts (which go under the ugly After School Special-ish name of "Web-Safe Fonts"), and if that computer happens to belong to a Free Software-only Diehard, you can't even count on those. If you have a font that looks nice, or one that's important to your brand, chances are Joe Average-User won't have it installed. If it's just one line of text or so, you can just put it in a graphic, but if you need to render things like article headings, usernames, or store names on the fly, you can't exactly create a image file each time. Moreover, at the risk of stating the obvious, an image is NOT text, so it won't be selectable, and accessibility software for visually-impaired visitors might not be able to read it.

sIFR is, by its own admission, a stopgap technology—not a permanent solution—to the persistent issue of fonts on the web. It works by creating a Flash file which embeds a subset of your chosen font, and then it uses JavaScript to dynamically pass specified text to that Flash file, which renders your text in the font of your choosing. And if the user's browser doesn't support Flash, no "bigs"; sIFR never switches itself on in the first place.

Given its complexity (HTML-through-JavaScript-to-Flash?!), I was worried that sIFR would perform poorly, but I've found it to be quite speedy. In terms of bandwidth, it only adds as much overhead as about ONE line of text-as-graphic, so in some situations it can actually save on bandwidth. From personal experience, rendering headlines in sIFR results in no noticeable performance hit.

Comments

ejr's picture

Broken functionality.

And now I cannot use the headline to open in another tab... But at least it does work with text-only browsing.

matt's picture

Interesting...

I hadn't noticed that, but you're absolutely right. The issue, of course, is Flash. Because sIFR renders headlines using Flash, all contextual control is surrendered to Flash (so right-click, for instance, is also neutered on those headlines).

For what it's worth, you can still Control-click on the text-based "Read more..." links that accompany each article. To avoid confusion, I might just disable links from those headlines on the front page and make the "Read more" links more prominent. I have no plans to use sIFR for any other links on the site.

Indie Bookstore Finder

FIND US ON:
IndieBound on Twitter IndieBound on Facebook

Indie Bestsellers

Lucky Us
Amy Bloom
Random House
Good Poems, American Places
Garrison Keillor
Penguin Books
The Paleo Kitchen
Juli Bauer; George Bryant
Victory Belt Publishing
The Great Glass Sea
Josh Weil
Grove Press

Make Your Own Wishlist






Update Profile