1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
|
Now let's imagine for a moment that you are a purist. You love strict XHTML as only a mother can. Let's suppose you're as rabid about your little baby's standards as Diane Ladd in "[http://www.imdb.com/title/tt0100935/ Wild at Heart]." How could we convince you that there is a practical application for Flash files, even in your twisted, lipstick-smeared world?
Well, we would criticize your typography of course. We already know your code is impeccable, but wow. Those headlines are still in Georgia huh? Kind of primitive, don't you think?
As web designers, we have reliable access to maybe six fonts that all users will have. This was one of the limitations of HTML that first drew me to Flash. Now, you may not be as obsessed with typography as some of us (if you know that Mrs Eaves is not Mr. Eaves wife, then you might be obsessed with typography), but wouldn't you like to use something other than Arial sometimes?
Well, I can't really help with the body text. But headlines, oh headlines, do I have a revolution for you. It's called sIFR.
First, a brief history. SIFR is not exactly a new idea, rather an improvement on an old one. Web designers have always disliked the limited selection of fonts available. The problem is that in order for a browser to render a font, that font must reside on the user's hard drive. How many universally available fonts are there? Well conservatively, probably about six: Verdana, Times, Arial, Helvetica, Courier, and Geneva. Trebuchet, Tahoma and Lucida are also widespread, but less so than the Big Six. If you're using stylesheets, you know that the only options for total compatibility are simple sans or serif declarations. You declare a sans-serif font for a block of text and it's the browser's decision as to which sans-serif font it uses to display the given text.
From a designer's standpoint, this situation is undesirable to say the least. So, way back when, some folks thought, "Hey, we could replace a headline with a graphic that has the same text, but as an image. That way we can exercise control over the typeface being used. We can use any typeface because it's an image."
While a solution, this is still less than ideal. For one thing, it means that every single headline must be generated by hand using some sort of image application. Even if you automate the creation process with scripts, this is impractical for all but the simplest of sites. Today's database driven, content-assembled-on-the-fly website engineer cannot afford to create a separate image for every single headline.
There is another problem. Actually there are several others, but the biggest one is that this technique effectively ruins the site for the visually impaired. Instead of tags that look like this:
<code><h1>This is my great headline</h1> </code>
You need something like this:
<code><img scr="mygreatheadline.jpg" alt="This is my great headline"></code>
A screen reader is going to read that whole second line aloud, and the person using it is going to be annoyed because you were too caught up in the appearance of the text to remember that lots of people don't care about the appearance.
So, allow me to introduce scalable Inman Flash Replacement. Yes, sIFR stands for scalable Inman Flash Replacement. The technique takes its name from the man who invented it, [http://www.shauninman.com/ Shaun Inman]. The scalable part was added by [http://www.mikeindustries.com/blog/ Mike Davidson], who improved on the original and maintains the current code. The technique is essentially the same as image replacement, but relies on JavaScript and Flash to dynamically replace XHTML text with Flash text.
Why is this better? Many reasons. Foremost, sIFR allows us to code our pages as we normally would. We can create a stylesheet and set the size and other parameters of a headline. With sIFR on the page, something amazing is going to happen. When the browser requests the page, a JavaScript class parses the page for a given variable and replaces it. In our example, we'll say that the element we want the replace is an <code><h1></code> tag, but it could be anything. Wherever the JavaScript finds that <code><h1></code> tag, it sets the text contained within the tag to "hidden" and then embeds a Flash movie matching the element's original size. The script then feeds the Flash movie the hidden text. Finally, like magic, the Flash movie displays the text it gets from the JavaScript.
There are no restrictions for which fonts we can and can't use within a Flash movie, so we can design our headlines however we'd like.
If the user doesn't have Flash, doesn't have JavaScript enabled, doesn't have either, or is using some assistive device, the original text is still there just as it would have been had we done nothing at all.
====How and when to use sIFR====
Mike Davidson, who maintains the code for sIFR, has [http://wiki.novemberborn.net/sifr excellent instructions] on the sIFR wiki that explain to use the code. For the sake of clarity, I'll walk through a quick example here.
To get started, [http://novemberborn.net/sifr/2.0.5 download the .zip file] containing the script. The package also includes the Flash movie template. Open the Flash template and double click on the movieclip that occupies the main stage. This will take you to the actual text box. Just change the font for the text box to whatever font you want to use and publish the movie. Upload the resulting .swf file to your site.
You can also try the <a href="http://digitalretrograde.com/Projects/sifrFontEmbedder/">sIFR Font Embedder</a> for Windows or <a href="http://ajaxian.com/archives/opensifr-tool-to-generate-font-files">OpensIFR</a> for Mac OS X (also works in Windows), which are applications that can create the font files without requiring you to own Adobe Flash.
Now we need to add sIFR to our XHTML and CSS files to make it work. The first thing to do is include the JavaScript using the <code><head></code> tags of XHTML.
<pre><script src="sifr.js" type="text/javascript"></script></pre>
Next, open the JavaScript file sifr.js. Near the very bottom of the file, you'll see a function call that looks like this:
<pre>
sIFR.setup();
</pre>
Just below that line, we're going to add another function call. The syntax is explained in the readme file that accompanied your download. The code I use on my site looks something like this:
<pre>
sIFR.replaceElement(named({sSelector:"h1", sFlashSrc:"http://www.mysite.com/path/to/sifr.swf", sColor:"#FEDB18", sBgColor:"#6f5f45"}));
</pre>
This calls the JavaScript function <code>replaceElement</code>. The sSelector parameter tells the function which tag to replace. The sFlashSrc parameter tells the function where to find the Flash movie. The sColor parameter controls the color of the font and sBgColor controls the background color of the Flash Movie.
In the example above, all the <code><h1></code> elements will be replaced. We could get more specific. In fact, you can be as specific or generic as you like with the sSelector parameter. Let's say for example that we only want to replace <code><h1></code> tags that occur in a <code><div></code> named body. We would just change our code to read:
<pre>
sIFR.replaceElement(named({sSelector:"#body h1", sFlashSrc:"http://www.mysite.com/path/to/sifr.swf", sColor:"#FEDB18", sBgColor:"#6f5f45"}));
</pre>
There are additional parameters that you can pass to the function to control things like hover states for links, transforming text to uppercase, and more. For a complete list of parameters, see the [http://wiki.novemberborn.net/sifr/How+to+use sIFR documentation].
====Putting sIFR on the page====
The next step is to include the sIFR classes in our CSS file. Open your CSS file in a text editor and add this code:
<pre>
.sIFR-hasFlash h1
{
visibility: hidden;
}
.sIFR-flash { visibility: visible !important; }
.sIFR-replaced { visibility: visible !important; }
span.sIFR-alternate
{
position: absolute;
left: 0;
top: 0;
width: 0;
height: 0;
display: block;
overflow: hidden;
letter-spacing: 0;
}
</pre>
This chunk of CSS does a couple of things. First, it creates a hidden selector class for the element we are going to replace. Then, the rest of the declarations handle the display of the replacement movie.
The primary thing were going to do with this code is use the class <code>.sIFR-hasFlash h1</code> to control the size of our replacement text. The creators of sIFR refer to this as "tuning" your fonts.
This tuning process can be a little tricky, and is essentially a process of trial and error. The goal is to make the original text the same dimensions as the replacement text. To do so, we can add declarations like <code>line-height</code>, <code>font-size</code>, <code>font-weight</code> and <code>margin</code> or <code>padding</code> to the <code>.sIFR-hasFlash h1</code> declaration. Unfortunately, there is no general solution I can give you. Some situations require more tuning than others.
If you open up the sifr.js file again and look near the bottom, just above where we inserted our function all earlier. You should see a function that reads:
<pre>
sIFR.setup();
</pre>
Comment out that line and add this one just below so you have:
<pre>
//sIFR.setup();
sIFR.debug();
</pre>
This will allow you to see your tuning in real-time. When you're done, just uncomment the <code>.setup()</code> line and comment out the <code>debug()</code> line.
The only other thing you'll want to do is change your print-css stylesheet to make sure your replacements don't happen when the user prints the page. If you're having problems refer to [http://wiki.novemberborn.net/sifr/show/HomePage the sIFR wiki] for troubleshooting and more detailed instructions.
There might be a temptation, given this newfound control over fonts, to go a bit crazy and use it everywhere. Resist that temptation. sIFR wasn't designed to replace everything on the page. Your body text is still going to be limited to the big six. sIFR is best used for headlines, and maybe subheadlines if you don't have too many.
One thing you may notice is a slight lag time before your headlines are displayed. On my MacBook, this little pause is about one second. If this bothers you, you can set sIFR to show the normal font before it replaces it with Flash.
I should note that you do not have to put the function call in the sifr.js file. In fact, sometimes you may not want to. You can also write it into the XHTML pages as well. Just remember to put it at the bottom so it doesn't slow down your page load times.
If you ever get stuck using sIFR, refer to the documentation or the wiki. And of course, nothing beats trial and error.
==sIFR in the Wild==
sIFR is all over the place these days, from ABCNews.com to the official Red Hat site. You can look at [http://wiki.novemberborn.net/sifr/Examples the official example page]. It's not always easy to tell when sIFR is being employed, and that's kind of the point. If you don't notice the behind the scenes stuff, then you are witnessing a truly seemless integration of XHTML and Flash.
Adhering to web standards is no longer an excuse to avoid Flash. At the same time, don't use these techniques to justify doing a whole site in Flash. Flash has its place. It does some things very well and other things are best left to XHTML.
Choose wisely, grasshopper.
|
