CMXtraneous: CSS

Right on the edge of useful

The Melodius Sound of Tuning your sIFR

Posted Thursday, February 24, 2005 6:08:03 PM by Stephanie


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. ;)

Category tags: Accessibility, CSS, Designing for the Web, Dreamweaver, Flash