sIFR or FLIR?

Question

I've recently bumped into facelift, an alternative to sIFR and I was wondering if those who have experience with both sIFR and FLIR could shed some light on their experience with FLIR.

For those of you who've not yet read about how FLIR does it, FLIR works by taking the text from targeted elements using JavaScript to then make calls to a PHP app that uses PHP's GD to render and return transparent PNG images that get placed as background for the said element, where the overflow is then set to hidden and padding is applied equal to the elements dimensions to effectively push the text out of view.

This is what I've figured so far:

• The good

  • No flash (+for mobiles)
  • FLIR won't break the layout
  • Images range from some 1KB (say one h3 sentence) to 8KB (very very large headline)
  • Good documentation
  • Easy to implement
  • Customizable selectors
  • Support for jQuery/prototype/scriptaculous/mooTools
  • FLIR has implemented cache
  • Browsers cache the images themselves!

• The bad

  • Text can't be selected
  • Requests are processed from all sources (you need to restrict FLIR yourself to process requests from your domain only)

My main concerns are about how well does it scale, that is, how expensive is it to work with the GD library on a shared host, does anyone have experience with it?; second, what love do search engines garner for sIFR or FLIR implementations knowing that a) text isn't explicitly hidden b) renders only on a JavaScript engine.

Answer 1

I know that with sIFR, and I assume with FLIR that you perform your markup in the same way as usual, but with an extra class tag or similar, so it can find the text to replace. Search engines will still read the markup as regular text so that shouldn't be an issue.

Performance-wise: if you're just using this for headings (and they're not headings which will change each page load), then the caching of the images in browsers, and also presumably on the server's disk should remove any worries about performance. Just make sure you set up your HTTP headers correctly!

Answer 2

since FLIR is IMAGES and sIFR is flash i would imagine that it would be a bit more resource intensive to use sIFR. I havent run any tests but it seems logical.

Search engines search sIFR better than FLIR because some search engines can go into the text of a flash document

Answer 3

Over the long term, sIFR should cache better because rendering is done on the client side, from one single Flash movie. Flash text acts more like browser text than an image, and it's easy to style the text within Flash (different colors, font weights, links, etc). You may also prefer the quality of text rendered in Flash, versus that rendered by the server side image library. Another advantage is that you don't need any server side code.

Google has stated that sIFR is OK, since it's replacing HTML text by the same text, but rendered differently. I'd say the same holds true for FLIR.

Answer 4

Thank you everyone for the answer and Novemberborn I guess you nailed it.

Text does render better in flash and I've also bumped into a dead end when I realized that in my design FLIR would often need to break the headlines and I'd need to call the server on every resize to update the images with new dimensions. That's a design concern everyone should have in mind.

Answer 5

I don't know much about sIFR because FLIR worked, and it "felt" better to me than Flash. Just looking at the sIFR 3 beta demo page I noticed that it doesn't seem to react to browser preference text resizing. That is, I increase my font-size in Firefox (ctrl-+) and reload the page, the headings stay the same size.

To those who know sIFR, is this an actual limitation of the script or did they just do the demo page wrong?

If it actually doesn't handle this, I'd call that a major advantage for FLIR, which does work this way. People with impaired vision who don't use screen readers probably don't appreciate that the text doesn't resize to their preference.

That said, from a quick glance at sIFR's API, you should be able to make resized text work in sIFR. I'd consider it a bug to be fixed, not an essential disadvantage of the method.