A short history of custom type on the Web

We can all remember back to the days where finding bits of information about font requirements were found next to the screen resolution requirements as well as browser requirements. Many times, the fonts were supplied with a quick hyperlink and after a quick download, unzip, installation, and restart of your browser you were ready to go! Luckily, providing a requirement such as that seemed to be short lived (although you still run across the issue as well as browser and resolution requirements to this day). With the implementation of CSS, developers and designers had much more to work with and were now able to use more effective techniques in their designs.

CSS based image replacement

Using CSS image replacement caught on like wildfire and many designers use it in nearly all of their work. Personally, I find myself using the technique at least once in nearly every project I work on, including this website. There are many different methods used for image replacement, each with their own set of pros and cons. A great resource to read about and view examples of various techniques is a post on mezzoblue entitled Revised Image Replacement. A number of methods are detailed including a short description, code sample, and live examples of each.

During the second revision of this website, I had come up with a technique for image replacement that I hadn’t seen anywhere else. The details are included in the write-up, but essentially it was the best way I could find to not bloat the code with extra markup while retaining accessibility as best as possible. Instead of trying to hide any of the content in the first place, I attempted to camouflage it using the color of an image. Please read more about my latest take on image replacement.

What is sIFR anyway?

As taken from WIKI.NOVEMBERBORN:

sIFR (or Scalable Inman Flash Replacement) is a technology that allows you to replace text elements on screen with Flash equivalents. sIFR is the result of many hundreds of hours of designing, scripting, testing, and debugging by Mike Davidson and Mark Wubben. Mike, Mark and an invaluable stable of beta testers, supporters, and educators like Stephanie Sullivan and Danilo Celic of Community MX completely rebuilt a DOM replacement method originally conceived by Shaun Inman into a high quality cross-browser, cross-platform typography solution for the masses.

In my opinion, sIFR is, in and of itself, quite a good idea as well as an evolved technique. Earlier versions of sIFR became available some time ago, and it is still being researched as well as developed to this day. The new beta releases are including new features, as well as rethinking implementation itself. My main question is: why is sIFR not more widely implemented? Is it because of the requirements placed on the reader in that they need to possess a third party plugin as well as have JavaScript enabled to run a check for that plugin?

While requirements placed on the reader may be slightly overbearing, sIFR was developed in such a way where it will gracefully degrade for your readers. Am I mistaken in my observation that sIFR is not implemented as much as you’d think?

In closing

As with any story, there are two sides with both CSS based image replacement as well as sIFR as choices for custom type in headings. There are accessibility issues attached to image replacement, and user requirement issues when dealing with sIFR. Which do you think is the better choice and why?

P.S. I’ve ended posts with questions before in hopes of getting some opinion from readers as I value their opinion. I’m hoping that those of you who don’t normally write a comment after reading the article can find a few minutes to do so on this. I’m truly interested in the reaction other designers and developers have regarding the two techniques. Thanks a lot in advance!