Today was the day to take sIFR over to two client sites. I've played
with it and even used it on one where it was only a “here and there”
thing. But today, it was a “get ready to deploy sitewide” thing. And so
the fine tuning began.
First, if you haven't been introduced to sIFR, get ready for a
treat. You're going to be hearing much more about it. I have some
earlier posts that link you to all the pertinent info — Accessible, Beautiful Flash Text, sIFR – The Release Candidate and sIFR Release Candidate 2 Has Arrived. Danilo Celic has a demonstration of sIFR usage and set up in his new Breeze (or is it Captivate?) demo live this week in Macromedia's DevNet center called, Introduction to Scalable Inman Flash Replacement (sIFR). If you have Flash MX 2004, you can automate the creation of an initial group of font swfs using Danilo's tutorial here at Community MX – Automating sIFR Font SWF Creation WIth Flash MX 2004 and JSFL.
If you decide to try it out, you'll want to look through Mike and
Mark's read me text for basic instructions. The basic explanation of
what I'm going to talk about here is — tuning is the act of making the
decoy text (styles affected by selectors such as: .sIFR-hasFlash #h1 ) take up the same amount of space as the Flash replacement text does.
Even though Danilo has made it simple to create the swfs and though
sIFR is quite easy to insert into your pages, I found the tuning
process to be a bit tricky. I thought I'd share some tips with those
that might also want to try it out. Here are the things I found in no
particular order:
- First, as recommended, temporarily replace the opening tag of your html element with this: <html class=”sIFR-hasFlash”>. Then, in your decoy styles, comment out all the “visibility: hidden”
declarations. This prepares your page to show you the actual decoy
styles (the ones that prepare the space for the sIFR replacement). - I found that using Firefox with Chris Pedrick's Web Developer's toolbar
while tuning was very handy for turning JavaScript off and on for
comparison — without reuploading the page. So for the rest of these
tips, I've used Firefox with Chris' toolbar. After any of the below
tweaks, I simply uploaded, viewed with sIFR, turned off the JavaScript,
refreshed the page, and viewed the decoy. - Since in my
regular selectors, I write my font values in relative sizes, the first
thing I did was put pixel sizes in my decoy styles. This gave me a bit
more of a level playing field. That said, increasing and decreasing the
pixel size in the decoy style can also change the size of your sIFR
replacement text, so keep that in mind. From there, I began the
tweaking of the letter-spacing and then the line-height. That's the
order that worked best for me. - If you've used more detailed descendant selectors in your style sheet, you'll want to change your decoy styles from this: .sIFR-hasFlash h2 to something like .sIFR-hasFlash #content h2
(or whatever mirrors your selector). I had an h2 element that
occasionally had a class on it (which caused me a great deal of
headache before I figured out what was going on). I was able to write a
selector like: .sIFR-hasFlash #content h2.separate
without a problem, so don't be afraid to get specific where you need
to. If you don't do this, the specificity of your regular styles will
override the h1, h2, h3, etc of the .sIFR-hasFlash styles if there are
similar declarations. For example, if you have line-height in both
selectors, and you don't write a decoy style with higher specificity,
your regular descendant h* style selector will override the decoy style
in specificity value and you won't know why the decoy isn't obeying. - If
you have long headlines, watch where the line break happens in the sIFR
and try to match it in the decoy if possible. This is usually done with
letter-spacing. - If you notice a slight “page jumping” as you
switch from decoy to sIFR, this likely means that one style is taking
up more space vertically. Try adjusting your line-height to make them
match. - In the bottom of your page, in the actual JavaScript
replacement statements, the order they're entered can matter. I had a
page with an h4 styled as a callout, with borders and padding and
margins. I found that Internet Explorer Mac was shifting the next
heading, an h3, to the right about 30px. (Internet Explorer Mac also
put the bottom border directly beneath the top border, as if nothing
was in between. I simply hid the border from IE Mac. But the shifting
was still happening.) I noticed as the page loaded that the h3 seemed
to be loading first and then getting shifted by the h4 above it when it
loaded. Changing their order in the replacements so that the h4 was
before the h3 fixed that little problem.
I still have a few things to work out. I want to play with floating
images in sIFR headings — so far, no go on that. I also had the idea
tonight that perhaps putting a font-family in my .sIFR-hasFlash style
might start me on a more level playing field each time. At least I'd
get used to the sizing of one particular font as well as how it reacts
to letter-spacing and and line-height. Today I was working with both
Verdana and Trebuchet MS fonts. They definitely react differently. I
also have seen a bit of difference in rendering between Firefox, Safari
and Internet Explorer. Someone gave me some ideas to try there next
time. I, and others, will probably be adding to the sIFR wiki. So come over there and join the fun soon.
Hopefully these tips are coherent enough for you to get a bit of help from them. If not, blame it on the cough medicine. 
{ 2 comments… read them below or add one }
What a fantastic reference! Thanks, Stephanie. I have saved this post as a PDF for future use.
Hey Stephanie, that’s really great.
sIFR is about the last frontier of experimentation for me before I go grey and/or bald with all the new techniques on the go.