Somewhere in the past, somebody forgot about typography when crafting the very ideas that would become standards in web publishing. Not completely, mind you; there do exist facilities to use custom typefaces on the Internet, but they are primitive and require everyone who visits a web page to already have a font on their computer. This worked for a while, but eventually people realized that they wanted more. Unfortunately, development in typography on the Internet hit a sort of standstill, and now the available tools for including fonts on web pages don't meet the demands of both developers and typeface copyright holders.

As is the way of the web, people demand progress. There do exist groups of standards bodies and type foundries trying to develop accepted ways of embedding type in the web. These things take time; they often take a lot of time. In the mean-time, clever people have been dreaming up their own ways of including custom typefaces in their documents. One of those, sIFR (Scalable Inman Flash Replacement) has become a quite popular solution. The idea behind sIFR is replacing existing text on a page with an instance of the Adobe Flash plugin which dynamically renders that same text in a custom font.

Screencapture of Jason Santa Maria’s blog, rendered virtually useless by broken sIFR

This is where my opposition begins. sIFR has been a somewhat controversial technique, even on top of the controversy that already existed with web typography. People have complained about its (lack of) usability and accessibility, its rendering speed; the list goes on. My complaint with sIFR is yet another: nearly every website I visit is broken by sIFR.

My web browser of choice is Google Chrome, both the stable and developer releases (versions 2 and 3 respectively at the time of writing). I have not had any other problems with the Flash plugin in the past from within Chrome, including very large applets which perform intensive tasks, such as high quality audio manipulation. Yet every time I view a page which uses the sIFR technique from within Chrome, the Flash plugin crashes. Obviously this is a huge usability problem. Depending on where and how many times the author decided to use sIFR on his or her page, I'm left with a mess of "broken applet" icons. With only the surrounding text and images for help, decoding what the text was supposed to say can be somewhat daunting. It’s worse still when the broken sIFR text is a link.

odopod’s main introductory title text, and all category headings use sIFR, all broken in this screenshot.

Undoubtedly the sIFR technique has many benefits, the ability to use rich typefaces being paramount, however in my opinion, the cons far outweigh the pros. The risk of breaking one’s site and alienating the user (especially one who might have no idea what has gone wrong – if they have that indication at all) is in my opinion overwhelming reason to not use a technology.

Web developers seem to have no problem going to great lengths to develop and test sites which are the utmost standards compliant, accessible, and which degrade gracefully for users who may not support the latest technologies, which is no simple task considering the vast matrix of operating systems, browsers, and technologies.. I fail to see, then, how it is acceptable to use something that under certain conditions (or for certain users) breaks a site consistently, every time. I must say, I'm glad to know that I am not alone.

Update (2009.12.10 23:06):

Jason Santa Maria has announced that he has switched from sIFR to Typekit (of which he is now the Creative Director); site no longer crashes. One down, many to go…