Geek Answers Handbook

SIFR or FLIR?

I recently came across a facelift, an alternative to sIFR, and I was wondering if those who have experience with sIFR and FLIR can shed light on their experience with FLIR.

For those of you who haven't read about how FLIR does it yet, FLIR works by picking text from the target elements using JavaScript and then making calls to a PHP application that uses PHP GD to render and return transparent PNG images. which are used as the background for the specified element, where the overflow is then set to hidden, and the addition is applied to the sizes of the elements in order to effectively bring the text out of view.

This is what I have guessed so far:

  • Good

    • No flash (+ for mobile phones)
    • FLIR will not break the layout
    • Images range from 1KB (say, one h3 sentence) to 8KB (very large title)
    • Good documentation
    • Easy to implement
    • Customizable Selector Functions
    • JQuery / prototype / scriptaculous / mooTools support
    • FLIR implemented cache
    • Browsers cache the images themselves!

  • Bad

    • Text cannot be selected.
    • Requests are processed from all sources (you need to limit FLIR yourself to process requests only from your domain)

My main concerns are how well it scales, that is, how expensive it is to work with the GD library on a shared host, does anyone have any experience? secondly, what kind of love do search engines make for implementing sIFR or FLIR, knowing that a) the text is not explicitly hidden b) is displayed only on the JavaScript engine.

+4
source share
5 answers

In the long run, sIFR should cache better, because rendering is done on the client side, from a single Flash movie. Flash text is more like browser text than an image, and it’s easy to style text inside Flash (different colors, fonts, links, etc.). You may also prefer the quality of text displayed in Flash over the quality displayed by the server-side image library. Another advantage is that you do not need server-side code.

Google stated that sIFR is fine, as it replaces the HTML text with the same text, but displays differently. I would say that this is true for FLIR.

+8
source

I know that with sIFR, and I believe that with FLIR you do your markup the same way as usual, but with an additional class tag or similar, so that it can find the text to replace. Search engines will still read the markup as plain text, so this should not be a problem.

Performance: if you just use this for headings (and they are not headers that will change the loading of each page), then caching images in browsers, as well as, presumably, on the server’s disk should remove any worries about performance. Just make sure you configure your HTTP headers correctly!

+2
source

since FLIR is IMAGES and sIFR is flash, I would suggest that using sIFR would be a bit more resource intensive. I have not performed any tests, but that seems logical.

SIFR search engines are better than FLIR because some search engines can jump to flash document text

+1
source

I don’t know much about sIFR because FLIR worked and it “felt” me better than Flash. Just by looking at the sIFR 3 beta demo page , I noticed that it does not respond to resizing text in the browser. That is, I increase the font size in Firefox (ctrl- +) and reload the page, the headers remain the same size.

For those who know sIFR, is this the actual script restriction, or did they just do the demo wrong?

If this does not really cope with this, I would call it a major advantage for FLIR, which works just that. Visually impaired people who do not use screen readers may not understand that the text does not change as they see fit.

However, with a quick look at the sIFR API, you should be able to resize text in sIFR. I believe that the error is fixed, and not a significant drawback of the method.

0
source

Woff files are the best solution.

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

0
source

More articles:


All Articles