Regarding future-proofing, I try my best to make sIFR future proof, but of course one can never be sure. Then again, how future proof is the CSS you’re using? With sIFR 3 upgradability should be better, because there are more detailed change logs. And personally I think v3 is much, much more stable than v2 :)

It’s important to understand that for our purposes we have no room for error. Any technology that we add to the site must not degrade or alter any functionality that existed before it. This site is viewed by hundreds of millions of users daily. We have a rigorous QA process and strict rules regarding usability and site speed.

The research I conducted was for the current stable version of sIFR. I did throw in a plug for v3 at the end but Beta software is not an option for us.

It should also be noted that sIFR for private use and sIFR for public use are wholly different considerations. On a blog such as this one for instance, I would be much more likely to use sIFR and other technologies (in the case of this post for instance I am using a combination of Thickbox and Flash Video for the demos).

Lastly I’ll mention that I deployed sIFR on numerous corporate sites several years ago and found its various quirks made for tedious integration and maintenance. I also found it very difficult to convince our clients that while sIFR worked perfectly for the sole h1 they could not however use it for every h2, h3 and h4 across the website.

I will elaborate briefly on some of your questions below.

Localization: In the US we might say “About Us” and most people would understand this to mean about the Company. In a foreign country however the vernacular or tone may be different. In some countries saying “About Us” is unclear, improper or otherwise lacking polish. For our German site we may instead say; “About Global Solutions Incorporated”. On the Dutch site we may say; “More Information about the services we provide”.

sIFR’s requirement of a fixed dimension make localization an enormous challenge. Assume that a 13 character English/US header can be replaced by a 36 character (or more) French/France header. Consider as well that a fixed height of 20px works for one language and another needs 10px or 40px to look right. Add to this support for 13 other languages including Japanese, Korean, Arabic and Russian and it quickly becomes a QA testing nightmare.

Extended character support: Superscript is the most obvious example I can think of.

Text wrapping: In order to support text wrapping the height of a header must be increased to support multiple lines. I don’t recall sIFR supporting dynamic height adjustment for wrapped lines.

Scalability: The ability to replace 1 to n headers on a page without affecting site speed. The ability to add support for languages to the site without an increase in development time.

Future-proofing: The case of Adobe upgrading Flash and breaking sIFR comes to mind. On a site of our scale and reach something like this would be a catastrophe.

Upgradability: Each change (especially to something like JavaScript, and Flash) requires another round of QA testing. How can we be certain that a new version does not introduce some new quirk?

Wmode support: The headers aren’t truly transparent if I recall correctly and I’ve encountered trouble with background images.

Dynamic text sizing: I’m referring to scaling and sizing differently here. I think of scaling as the ability to grow and shrink the page and sizing as the ability to grow and shrink the fonts. To an extent I am also referring to the text wrapping issues I mentioned above.

Z-index collisions: The dropdown menu of Offbeat.com is an example of this. In my past experience I had no luck combining DHTML menus with sIFR headers on a page. This was especially noticeable in Safari.

* localization: What do you mean by this, precisely?
* extended character support: sIFR supports all characters which are supported by Flash, which gets pretty close to UTF-8
* fouc: When implemented correctly, you don’t see HTML text before it’s replaced by sIFR text
* page zooming,: This is supported in sIFR 3
* text scaling: Implemented via page zoom
* text wrapping: Not sure what you mean, but sIFR supports wrapped text and will wrap text after a window resize
* page load: sIFR 3 starts replacing text on DOM load, which tends to be earlier than what sIFR 2 did, though this depends on the implementation.
* cpu load: Well, yea. Blame Flah ;-)
* scalability: How do you mean?
* UTF-8 compliance: This is fully dependent on Flash, but I think it’s good enough
* QA testing: Heh, ouch! sIFR keeps improving though
* Future-proofing: Please elaborate
* Upgradability: Please elaborate
* Wmode support: Are you referring to poor wmode support in Firefox? This should be resolved in Firefox 3 I think, though I haven’t properly checked that. And on Linux there’s no support for transparency, but sIFR will fall back to a solid background color
* Dynamic text sizing: Is this the same as text scaling?
* DOM support: Eh?
* Z-index collisions: You’ll need wmode for this, then it should work.

Would love to hear your feedback!