4

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.

Filip Dupanović
  • 32,650
  • 13
  • 84
  • 114

5 Answers5

8

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.

Mark Wubben
  • 3,329
  • 1
  • 19
  • 16
2

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!

nickf
  • 537,072
  • 198
  • 649
  • 721
1

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

Russ Bradberry
  • 10,705
  • 17
  • 69
  • 85
  • yes sIFR would be more resource hungry on the client, but not on the server, which is the part you are generally responsible for. FLIR will be heavier on the server. I think the search engine will see the normal markup in both cases as the javascript will not be run. – Tom Haigh Dec 22 '08 at 23:37
  • is it really easier for the server to create a flash document than an image? i wouldn't think so. – Russ Bradberry Dec 22 '08 at 23:44
  • Russ, sIFR is completetly client side, so the server does not create anything. It just serves up a few static files. – Mark Wubben Dec 25 '08 at 15:05
  • To clear this up, sIFR uses an previously-compiled Flash which gets parameters on the client-side. So the server does not do any work. Which is exactly what Tomhaigh says... IN ANY CASE Russ's answer is correct about Flash docs... – Dan Rosenstark Dec 26 '08 at 14:09
0

Woff files is the best solution.

http://www.fontsquirrel.com/tools/webfont-generator

nixis
  • 510
  • 5
  • 10
  • Note that link-only answers are discouraged (links tend to get stale over time). Please consider editing your answer and adding a synopsis here. – kleopatra Jun 20 '13 at 17:12
0

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.

Jerph
  • 4,572
  • 3
  • 42
  • 41