There are almost as many techniques for image replacament as there are Web developers. The concept behind all these image replacements tricks is that the text normally displayed by HTML is hidden and replaced by an image. This means that any user with a CSS-enabled browser will see the replaced text, but the user agents that don't support CSS will just see the plain text

One major downside of image replacement is that it requires a lot of manual labor. Every heading that you want to include on a site has to be created in Photoshop, cut up, saved as an image, and included in your CSS.

If you’re creating content regularly, this work can become very time consuming; sometimes it’s just impossible. Imagine a site that has a content management system with multiple authors, none of whom have access to—let alone know how to use—a graphics program. It’s simply not feasible to have someone there just to create image-replaced headings.

But what if you had a system that automatically created nice headings, in a typeface of your choice, without you having to do anything to the HTML? That would be heaven. And there is such a system: sIFR.

Scalable Inman Flash Replacement is now in its second version (with a third already in beta) and, after being around for a couple of years, is rock solid. You’ll need to download some source files from the sIFR homepage in order to get it going. Don’t worry, I’ll wait around while you download it.

sIFR works like this: you include a JavaScript file on your pages that scans for headings, copies the text from inside those headings, and uses that text inside a Flash object that replaces the HTML text. The Flash object contains the font you want, so the text is automatically formatted the way you want it, and you don’t have to do any customization work. sIFR also scales the Flash object appropriately to fill the same amount of space that the HTML text occupied, so your text replacement will be the same size.

Technically, the HTML text isn’t replaced, it’s just hidden, so the text remains fully accessible. If Flash isn’t available, the sIFR JavaScript detects that and leaves the page untouched; if JavaScript isn’t turned on, the page will remain in its normal state. This way users see nice headings if their browsers allow it, but if their browsers don’t handle these headings, they degrade to perfectly readable text.

The next illustration shows the result when sIFR is unavailable, due to the user’s lack of either Flash or JavaScript. The HTML text acts as a backup and provides an approximation of the designer’s real vision. It’s a win–win situation! Those users who have Flash and JavaScript reap the benefits; those without are none the wiser.

It’s more likely with Flash replacement than with image replacement that some of your users will experience the degraded version, so you should pay careful attention to the styles that they will see if Flash and JavaScript are turned off.

Let’s imagine that the font we’d really like to use for our h1 headings is Cooper Black, but we know that not many people have that on their computers. Instead, we’ll have those users view our headings in Georgia, or some similar serif font:

flash-replacement.css (excerpt)

Note: sIFR can be affected by extra whitespace inside your HTML tags. For code readability, I normally write my HTML like this:

<h1>
Going to the snow!
</h1>

The actual HTML text is on a new line and indented one more tabstopthan the tag itself. However, with sIFR, that whitespace that appears before the HTML text will produce a one-character space at the beginning of the Flash replacement—not good! To use this technique, you’ll need to code your HTML as follows:

<h1>Going to the snow!</h1>

No spaces, no worries. The basic page looks like the illustration below.

Time to make it all Coopery!

The quest to allow Web users access to a wider range of fonts on HTML pages has been regularly thwarted by patchy browser implementations and the legalities of sharing typefaces. sIFR circumvents these limitations by embedding a particular typeface inside a Flash file. In order to use a particular font on your site, you have to open up the special sIFR Flash template and create a new .swf file that copies the font from your computer.

It’s really easy to do this. As shown below, we just open up sifr.fla, select the text object on the stage (the one that says “Do not remove this text”), and change its font to the one we need. Then, when we publish that movie as a .swf, it will contain all the data needed to reproduce the headings in that font.

Don’t have the IDE? Never fear, multiple repositories of precompiled sIFR .swfs are available on the Internet, giving those users without the Flash IDE a wide range of fonts to choose from In fact, one of them happens to be maintained by an author of this book!

You should generally call your .swf files by the fonts that they include, so that you can identify them easily later. As we’ve just created a .swf for the Cooper Black font, we could call the .swf file cooper_black.swf. Once we have this .swf, it’s ready to be included on the web page.

There’s one script file that we need to include on the web page, and that’s sifr.js—you’ll find it in the package you downloaded from the official sIFR site. To start out, it just needs to be inserted in the head of your page:

flash-replacement.html (excerpt)

<script type="text/javascript" src="scripts/sifr.js"></script>

You’ll need to take a look inside the JavaScript file to configure the file specifically for the site. You don’t need to be concerned with most of it—it’s 11KB of tricky Flash detection and DOM manipulation—but right at the bottom you’ll see these few lines:

Don’t remove any of that code; you’ll have to insert some of your own code in order to indicate which headings you want to replace and what you want to replace them with:

scripts/sifr.js (excerpt)

sIFR.replaceElement specifies a replacement rule that you want sIFR to apply. You can have as many of these as you like, each effecting a different type of element. The function takes a number of arguments that effect the display of the Flash replacement. There are a few of these arguments, but the named ones you’ll use most often are:

• sSelector
  sSelector is the CSS selector defining element(s) that you wish to replace. It uses a simplifi ed CSS syntax, allowing you to select elements using the CSS selectors “#”, “>”, and “.”, as well as the whitespace descendant selector. If you select multiple elements be sure to separate them with commas: “,”.
• sFlashSrc
  sFlashSrc defines the location of the Flash movie you want to use to replace the text. This file determines the font you’ll be using for your Flash replacement.
• sBGColor
  sBGColor defines the background color you wish to use for the Flash replacement.
• sColor
  sColor defines the color of the text in the Flash replacement.
• sWmode
  sWmode defines the Window mode of the Flash replacement object. It allows you to set the transparency of the movie, and can be specifi ed either as transparent or opaque. In transparent mode, sBackgroundColor will be ignored and the movie background will be transparent. In opaque mode the background color will be displayed. Some browsers have trouble displaying transparency; in such cases sWmode will fall back to the opaque mode. Just in case, make sure you set a background color even if you choose to use transparent mode, so that you won’t be caught out in this situation.

You can supply to the function any of a number of other arguments, which will control everything from text transformation to alignment and padding. If you wish to read about them, the best place to look is in the documentation that comes with the sIFR package.

Once that replacement rule has been added to the end of the sifr.js file, it will perform that replacement when the page loads. Using the rule above, our page would look like the illustration below.

You’ll notice that the heading is now shown twice. The upper display is the Flash replacement, the lower is the HTML text. They’re both displayed simultaneously because we haven’t yet included any of the special sIFR CSS.

Inside the sIFR package is a CSS file called sIFR-screen.css, which we should include if we want the Flash replacement headings to display properly. This CSS hides any HTML text that has been replaced by Flash, so we don’t see the double display as shown above. Once we include this file, the page should look like the next illustration.

sIFR-screen.css contains several default rules for h1 to h5 elements that help to determine the dimensions of the Flash replacements. In order to understand how you should use these rules, you need to understand how sIFR does its job and how fonts relate to one another.

You saw above that the Flash replacement and the HTML text are different lengths when displayed side by side. This discrepancy arises as a result of the fact that the font used in the Flash replacement differs from that used in the HTML, and because different fonts have different character metrics (including width, spacing, and so on). This difference in length becomes a particular problem when a line of text starts to wrap onto the next line. If the HTML text isn’t wrapping but the Flash text is, sIFR will shrink the size of the Flash text so that it fits onto one line. This means that the size of the Flash replacement may be inconsistent, depending upon the number of characters in the HTML text. Conversely, if the HTML text is wrapping when the Flash text isn’t, then the sIFR will make the Flash characters really big in order to fill the space taken by two lines of HTML text. If the metrics of the Flash text don’t match the metrics of the HTML text, the size of the Flash text will become variable for different character lengths. Compared with the previous figures, the Flash text below is smaller.

In order to let you pre-empt this potential problem, sIFR applies a class to the HTML element to let you know when Flash has been detected: sIFR-hasFlash. You know that once this class has been applied the HTML text will be replaced by Flash, so you can tweak the text properties of the HTML to match the properties of the Flash text, achieving the same character heights, linelengths, and so on.

In order to ensure our Cooper Black Flash text displays at the same length as our Georgia HTML text, we can modify the letter-spacing, giving the Georgia font a bit more space between characters to stretch it out:

To see your tweaked HTML text alongside the Flash replacement, comment out the style near the top of sIFR-screen.css that applies to the sIFRalternate class, like so:

When you examine the comparison below, you’ll notice the heading lengths are almost identical:

As you can see below, with proper metric adjustment of the HTML text, Flash replacement maintains consistent sizing through varying character lengths and multiple lines.

Once you’ve tweaked the metrics to cause the headings to appear exactly as you want, remember to add visibility: hidden to the rule, so that the user doesn’t see the HTML text being distorted while the Flash replacement performs its calculation:

sIFR-screen.css (excerpt)

After you’ve implemented all these changes for your particular font, you can sit back and relax. sIFR will now automatically change any h1s on your pages to Cooper Black without your having to lift a finger.

sIFR is superb for headings that require a unique typeface. However, it lacks the flexibility of image replacement. You can’t distort the text, apply image masks, or make any other radical changes to the text beyond what Flash can normally do to text.

The other disadvantage to sIFR is that it can be a little resource-intensive. If you have a number of Flash-replaced headings on your page, the calculation time can weigh down page loading and affect the responsiveness of your interface. For that reason it’s a good idea to use it sparingly and not apply it to large slabs of body text.

sIFR can also replace links, but you do lose some natural link functionality simply by way of the link being in Flash. Right-clicking the link won’t bring up the normal browser context menu; mousing over the link won’t indicate where it will lead. So, as with anything that could impact on usability, use sIFR carefully and with full knowledge of the consequences.

Excerpted with permission from The Art & Science Of CSS (SitePoint) by Jonathan Snook et al. Copyright © 2007 SitePoint Pty Ltd