sIFR 2.0: Release Candidate 2 is Finally Here

UPDATE: Version 2.0 is now available. See article here.

Alright, sIFR Release Candidate 2 is finally here. It’s been exactly two months since Release Candidate 1 and we’re happy to say that things have held up very well so far. Release Candidate 2 fixes a handful of minor issues, and barring any regression behavior which may turn up in RC2 (but probably won’t), we think we have a solid 2.0 release on our hands. Thankfully, we’ve taken care of this before the end of 2004, because according to the 2005 Web Design Forecast, sIFR will be a huge part of the emerging typographical landscape in the coming year.

We couldn’t agree more.

Before I get into the details of RC2, I just want to thank Mark Wubben for a) all the great javascript work he’s done on sIFR, and b) all the helpful support he’s provided to people asking for assistance in the comments. There have been over 700 comments on all sIFR threads so far, and Mark has managed to successfully attend to almost all of them which pertain to javascript or implementation. So once again, thanks Mark for being so helpful, and also for being a genius.

I also want to thank Danilo Celic and Stephanie Sullivan of Community MX for their help in bringing sIFR to the masses. Check out Danilo’s Breeze Presentation for a great overview of sIFR and also a peek at the power of Macromedia Breeze. I love Breeze more every time I see it.

And finally, two more thank yous. One to Zen Master Dave Shea for his helpful, even-handed, positive review of sIFR, and one to Sean Schroeder for his beautiful sIFR work on Prosper Magazine.

Oh yeah, and I almost forgot, Wes Carr and the folks at 2Entwine have taken sIFR and expanded it into Fotobuzz.org, a photo annotation engine. Instead of replacing text with sIFR, Fotobuzz replaces images for the purpose of annotating them inside Flash. It is really really slick. Make sure and check it out.

Now… on to the details.

First of all, to upgrade to sIFR 2.0 RC2, you need only re-export your .swf files and pop in the new sifr.js file. No implementation details have changed. So in other words, upgrading should only take a minute.

Here’s what we’ve improved/changed/fixed:

  • sIFR now works in all reasonable versions of Opera. This should include all flavors of 7.x on both platforms.
  • URLs of unlimited length are now supported. Flash unfortunately has a 128-character URL limit on textfields, but we’ve gotten around that with some crafty coding.
  • Newline support is now added. If you place <br />'s in your replaced elements, they will now be honored.
  • HTTPS is now supported for domain-protected files.
  • sIFR now uses exact domain matching for domain-protected files. As a result, two-part domains like .co.uk are now eligible for protection.
  • Various speed improvements.
  • Minor selector bugs have been squashed.
  • Browser detection is now exposed in the javascript so you can easily disable sIFR for any browser you’d like.

At this point, we believe all outstanding issues are now resolved. Please feel free to download the new release and let us know what you think! The instructions are now contained in a readme.txt file within the zip archive below.

127 comments on “sIFR 2.0: Release Candidate 2 is Finally Here”:
  1. Nick Cowie says:

    Thank you!

    Time to go and play and see how it works.

  2. Awesome! I can really tell that there has been a speed upgrade; before, highlighting sIFR text was slow, trippy, and the text didn’t always even get highlighted. Now it’s much, much faster and cleaner.

  3. Gerrit says:

    Thank you so much, you are great coders! Are bug reports still to be placed here as a comment? Okay then. Now SAFARI finally shows german “Umlaute” like ä, ö and so on. Very cool. BUT: If I use the uppercase-option of sIFR, the “Umlaute” won’t go uppercase. This is a very specific problem, I know. But for german webdesigners it would be very nice if you could fix that.

    Example (Only in Safari)

  4. Olly says:

    Rock on! I’ll be sure to check this out.

    By the way, the permalink to this entry won’t open in Internet Explorer 6 on this machine (XP SP2), though its fine in Firefox. Instead I get the File Download dialog. Other permalinks open fine.

  5. Mark Wubben says:

    Gerrit, this is a bug in Safari. For some reason Safari’s JavaScript implementation cannot uppercase those characters.

  6. sunshine says:

    Using IE6 Win SP2 I’m having issues… but only sometimes. I had this problem with release candidate 1 as well but I thought I would wait for a new one and try a fresh start.

    On whitespace I see the headers no problem.

    On both your blog and design by fire I get blankness where the replacements should be.

    On your latest test page and my own feeble attempt, the status bar never gets to the end and reports that there are “x items remaining” where x is the number of replacements on the page.

    I’m convinced it’s something I’m doing but I’m not sure what.

  7. Mark Wubben says:

    Hey sunshine,

    We are aware of this problem and a workaround has been in the sIFR code for quite some time now. We’re going to need a bit more information from you to see if we can replicate your specific problem. (And, perhaps, some more bug reports.)

    Also it should be noted that Design by Fire is still using an old version of sIFR (or perhaps even IFR?).

  8. Jeff Croft says:

    Thanks again Mike, Mark, Shaun, and everyone else who is responsible. This sounds like a great release — I’m looking forward to giving it a go…

    Sunshine-

    I don’t believe Paul is using sIFR on Whitespace. It sounds to me like you’re actually have the problem all the time. Do you have problems with other Flash content?

  9. Mark Wubben says:

    Jeff and sunshine, the problem appears to be that IE has trouble loading the Flash file, the solution Mike found was to force an innerHTML change – just as I did to force Safari to repaint.

    Meanwhile Mark goes on checking if some Mozilla bugs have already been squashed….

  10. MikeH says:

    nice update, interesting to hear that 2entwine is using it for photobuzz

  11. Ben Pickles says:

    Links passed to the Flash file seem to stop at the first “&” sign – whether it’s an “&” or a “&”. This didn’t occur in RC1, is anyone else seeing this?

    Ben

    (Editor’s Note: Oops. We just fixed that. Re-uploaded a new RC2 at 12:55pm Pacific Time today, Monday, December 6th. Thanks for the alert and sorry for the oversight.)

  12. Ed says:

    First, great work, and thank you.

    Second, the new script conflicted with some js generated layers, with the sIFR replaced content forced to the top (above layers generated by Aaron B’s ypSlideoutMenu). I can’t show you an example, but I narrowed down the difference between RC1 and RC2 that caused it.

    On line 333, RC2 says “transparent” : “”;. In what I believe to be the equivalent code from RC1, line 265, it said “transparent” : “opaque”;. I don’t know what I’ve potentially broken by adding “opaque” back into the RC2 script, but at least the layers are now stacking correctly in Win IE 6 and Firefox 1. So, I’m happy for the moment, but I don’t know if that may cause bigger problems for others.

    Lastly, RC1 (and previous versions, I believe) incorrectly stacked layers only in Win Opera 7.54, but RC2 doesn’t replace the headline content at all (with either original RC2 sIFR.js or my edited version). Again, not so much an issue in my eyes, but it could be a sign of bigger problems for others.

    Thanks again to Mike, Mark, and everyone else!
    -ed

    (Editor’s Note: We actually decided to change the way window modes were handled in this release. Before, “opaque” was the default. Now, “” is the default. “” is a better default because it takes up less processor power if you don’t need stacking. If you do need to stack DHTML elements though, “opaque” is still supported. We added the ability to pass this in as the last parameter of the function. See the readme file for details. Please also make sure you have the lastest RC2, which was uploaded at 12:55pm Pacific Time today, Monday December 6th.)

  13. Joen says:

    I have just deployed it, and I must say it has some very nice improvements.

    Some of my main woes with RC1 was related to the way links were handled. Nearly all of those problems were caused by Macromedia, not sIFR. However, one specific issue was that Firefox on Windows had trouble with links. More specifically, if a page was scrolled, it would require a double-click on a link, as if to first “activate” it, and then follow the link. It is a pleasure that this bug has been fixed in RC2, whether you were conscious about it or not.

    As an added benefit of the above bugfix, I’m now using a hover color, and related to that I’d like to add to a wishlist for the final release that you plainly use textfields for links and hovercolors, and not have them reside inside a button, or movieclip as seems to be the case now. The benefit of this would be that links can be right-clicked / copied. While this’ll be a hassle to program, I’m fairly sure it can be done, and I honestly think the – albeit small – usability improvement would be worth it.

  14. Mark Wubben says:

    Joen, I only discovered this fix today, and we sort of smuggled it into the release. This prompted the problem Ed wrote about. Then there was the problem Ben pointed out.. it’s been a crazy 2 hours fixing it all again!

    We’re running the latest tests now, Mike will make an announcement in the post itself when we’re done. RC 2.1 ;-)

  15. Mark Wubben says:

    And it’s there…. I’ll write about this all some more tomorrow. Now it’s bedtime for me!

  16. Ed says:

    You guys rock. If I ever meet any of you, I’ll buy you lunch. Or cookies. Your choice.

    Stacking problem solved, and I’m glad to know it was only broken in an effort to save some processing power.

    It may just be my browser/settings, but Win Opera 7.54 still doesn’t replace headlines with RC2, even though it worked (somewhat) with RC1. Was that intentional? Replacement doesn’t even work with the sample page included in the RC2 package.

    Thanks!

  17. Marc Broad says:

    Mike, Mark – Thank you thank you thank you

    Squashing the floated link element bug has made my day. I have very boring days obviously. Great work once again…
    Superlative.

  18. Krzysztof says:

    Great to see new version. It’s really faster now.

    Opera (7.54, Win XP) replaces sIFRed elements only when identifies itself as IE 6 or any Mozilla, even in package v2.1. Opera as Opera – it doesn’t work.

    Other thing: please do name differently new zip files with changed sIFR versions, let it be 2.1 or 2.0b.

  19. Marc Broad says:

    Ok, running the risk of missing the obvious and being the first to incite the phrase “Read the instructions” – Has anyone managed newline support? I cannot seem to get flash to honour my new
    requests.

    And after a few minutes I asked rather forcefully. Still no luck.

  20. david gouch says:

    Doesn’t work at all in Opera 7.60 Preview 4.

    That doesn’t really matter (a barely-used preview version), but it’s information.

  21. david gouch says:

    More information.

    Opera can spoof its identity. When identifying itself as Opera, no text is replaced. When I change the identity to IE or Mozilla, it works perfectly.

    Again, this is all with Opera 7.6 Preview 4.

  22. Justin says:

    It seems that there is still no support for applying the “letter-spacing” attribute to the replaced text. Any idea as to whether this will be possible soon?

  23. Momo says:

    Opera seems still to be an issue, because in sIFR2.0rc1 the replacement in Opera Version 7.54 works just fine.

    But with Opera 7.54 (Build 3870) and sIFR2.0rc2 there isn’t any replacement.

    Any idea?

  24. Ben says:

    Just out of curiosity, why aren’t you using sIFR on your own site?

    Ben

  25. Mike D. says:

    Justin: Nope, unfortunately Flash simply doesn’t support letter-spacing on dynamic text. There’s currently nothing we can do about this since it is internal to Flash, but Flash 7’s CSS support may help with this in the future.

    Ben: Uh, I do use sIFR on this site. Every headline on every page uses it.

    Everyone: It appears we are still having some Opera issues. Opera is the bane of Mark and my existence right now… we will work to solve shortly.

  26. Dw says:

    I’m looking to use this technique with a specific font, but don’t own any of the MX products. Would anyone be willing to write out a SWF file for me with a particular font I have? If so, drop me an email at RetractableRoof@gmail.com.

    Thanks,
    Dw

  27. cheekygeek says:

    Downloaded the latest RC and noticed in the README that in addition to upgrading to the new sifr.js you are to Export the font.swfs over again. Why is that? What do we lose by using our existing font.swf files?

  28. Mark Wubben says:

    CheekyGeek, the ActionScript in the Flash file has been updated. We had to change the way links work because Flash has a 128 character limit on URL’s in textfields. If you don’t use your existing swf files you won’t be able to open links.

  29. casey g says:

    I just tried viewing the sIFR example on a Sony Ericsson T610 and it worked a treat! Can’t wait to implement it on a project.

  30. goetsu says:

    is it possible to make the sfir element resizable? (like normal text)

  31. Mark Wubben says:

    goetsu, while this is possible, it isn’t practicable. There is no reliable way to detect a text resize, and we’ll have to remove and then add all Flash elements. Also, as sIFR is mostly used for headlines, I don’t think it’s such a big deal if the headlines don’t resize, but the text does.

    There have been some people (forgot the link, sory) who have done this with Flash 7, but Flash 7 isn’t spread widely enough yet.

  32. cheekygeek says:

    Thanks for the explanation.

    I know just enough programming to be dangerous, so take this with a large grain of salt, but… gmail and other sites are using a javascript function called xmlhttp.

    Currently, sIFR is a nice html/javascript solution (VERY nice). I’m just wondering if even more could be done with the technique for users with PHP or ASP pages. This changes the focus from the client side to the serverside as the user still gets back straight html/javascript. Perhaps this is outside what you wanted to do with the project and/or I’m talking out my posterior.

    As I understand it (perhaps not at all) it allows “mini” requests that allow part of a page to update without reloading the entire page. Might this be useful in sIFR (or perhaps are you already using it)?

    http://www.devx.com/getHelpOn/10MinuteSolution/20358
    http://webpages.charter.net/mmmbeer/code/iframe/

    Naturally this works with only certain browsers (that support the javascript function) which is why you need certain browsers to be able to log-in to gmail. But it occurred to me that you might be able to provide additional functionality to those browser users with sIFR.

    Or not.

    Either way, this is great great stuff.

  33. Ezku says:

    I’m running Opera 7.60 preview 4 with WXP SP2, and I noticed the following things:
    – This site: no replacements if set to identify as Opera, cannot select replacements
    – The example: works all ways

    However, it was rather different with IE6:
    – No replacements on this site
    – No replacements on the example
    (- There seems to be a curious bug that messes with the design, as the menu on the right gets displayed after all the content on the left. Could admittedly be a thing with my ad blocker, but I haven’t had it cause anything like this before.)

    I’m guessing Mike is using an old version of IFR with Opera blocked on this site, but my IE6 is a mystery.

    Looks nice nevertheless, and I’m looking forward to getting to use sIFR in a design.

  34. Mark Wubben says:

    Ezku, thanks for the information. Mike isn’t using the latest version with fixed Opera and text selection support yet, however this the example page uses the latest version.

    (Editor’s Note: Thanks. Now I am.)

    As for IE6, I bet you are using SP2. There have beena few more bugreports for this version, but when trying to track down the bug they weren’t reproducable (I’m using SP1 myself, by the way).

    Anyone, if you see these problems and if you are able to reproduce them between different IE sessions, please contact me.

  35. Mark Wubben says:

    CheekyGeek, sIFR creates Flash objects and passes some information onto the Flash movie. This then displays much cooler text. The Flash movie works on the client side, though.

    There is a sIFR implementation which works with images. See .IR.

  36. WOW !
    Compliments on you guys “YOU ROCK”
    I was just wondering, is it possible to get the stuff like background color textcolor, from a linked css ? so We wouldn’t have to edit the parameters.
    but could do it from the central css I mean, textsize is specified there so why not color ?

    Anyone got any tips examples that would be cool !!!

    Vinnie

  37. Cameron says:

    Looking good Mike :)

    ..on screen anyway ;) – am I right in thinking that it doesn’t work in print, or am I doing something wrong? When I print-preview or print your example page from IE6 or FIrefox (Haven’t tried any others) I see un-sIFR’d fonts (ie the HTML version) – is that intended?

    Cameron

  38. Shane Graber says:

    I, too, would like to try this out but I don’t have what it takes to create the .swf files. Would someone be willing to do this for me if I would specify the font? What would be nice would be to have some sort of .swf repository so people could try this out easier.

    Shane

  39. Shane Graber says:

    BTW my email is sgraber@gmail.com.

    Thank you.

    Shane

  40. Julian says:

    Great Work!

    RE: Transparent backgrounds on Safari and Opera displaying as green…

    It would be great if there was a way of specifying a (fallback) background color for the browsers that don’t support transparency? …other than green :) Why is it green anyway?

  41. goetsu says:

    Mark wrote:

    Also, as sIFR is mostly used for headlines, I don’t think it’s such a big deal if the headlines don’t resize, but the text does.

    >> it’s a big deal for accessibility, there is not only blind people most of people simply increase the size of the text. I know it’s not possible with flash6 but it was great if you make it an option to choose or not.

    thanks

  42. usui says:

    A question. An English title is displayed satisfactory. But, Japanese is not changed. Is there a problem somewhere?

  43. ElRocco says:

    Hey there,

    Awesome job… on sIFR! The only thing is that I still can’t get anything to print…

    I’ve seen a few places where the sIFR implementation prints fine (the sample page and one of the trackbacks on this entry) but others where it doesn’t print anything at all (what I’m trying to do and the other trackback on this entry!)…

    Can anybody help me?

    Here’s what I have in my css:

    the screen css contains this:

    .sIFR-flash {
    visibility: visible !important;
    margin: 0;
    }

    .sIFR-replaced {
    visibility: visible !important;
    }

    span.sIFR-alternate {
    position: absolute;
    left: 0;
    top: 0;
    width: 0;
    height: 0;
    display: block;
    overflow: hidden;
    }

    .sIFR-hasFlash h1, #teaserpunchline h3 {
    visibility: hidden;
    }

    ###########

    The print css contains this (which is straight out of the example):

    /* This is the print stylesheet to hide the Flash headlines from the browser… regular browser text headlines will now print as normal */

    .sIFR-flash, .sIFR-flash object, .sIFR-flash embed {
    display: none !important;
    height: 0;
    width: 0;
    position: absolute;
    overflow: hidden;
    }

    span.sIFR-alternate {
    visibility: visible !important;
    display: block !important;
    position: static !important;
    left: auto !important;
    top: auto !important;
    }

    Thanks in advance.

  44. Mark Wubben says:

    Wow, lot of comments here!

    Vincent, my fellow Dutchman, sIFR doesn’t actually get the font size from the CSS, it takes the height and width which the element is rendered with. This is also the reason why you have to specify padding: so we can detract it from the dimensions of the element.

    Unfortunately selecting colors (and padding) from the CSS is not an option because there are a lot of (sometimes old) browsers which don’t support this. One of these is Safari, I think you’d agree with me we can’t let that one out in the cold!

    Cameron and ElRoco, browsers aren’t very good at printing Flash, that’s why there is some CSS in the example which shows the original text and not the Flash. The reason you don’t see this everywhere is because some people aren’t using this specific CSS.

    (ElRoco, if you remove the print CSS you can print the Flash.)

    Julian, thanks for the idea. The problem however is that it’s going to take a lot more browser detection to make sure the fallback is used in the right occasions. Plus, I don’t know the exact browser versions in which this problem occurs (…yet, I can do some tests to figure that out). Let’s see what Mike thinks about this.

    Goetsu, I don’t think it would be that bad. As for me, I resize the text to read the text, not the headlines. If you really want to, you can reload the page and the headlines will be larger. The technique used to resize with Flash 7 will make things a bit more complicated as well. I (and Mike) don’t think it’s worth the effort.

    Usui, you have to make sure the Japanese characters are in the Flash file.

  45. Danilo says:

    Great work folks!

    Eveyone I talk to about sIFR gets excited about it, so I was glad to have made the Breeze presentation.

    I’ll be presenting to my local Macromedia user groups (Chicago area) on the topic, so I’ll be spreading the word even more.

    Also I’m working on a Dreamweaver extension that will combine Dreamweaver and Flash to help folks automate the production of font SWFs for use with sIFR. As long as things go well, I should be able to have something in a testing state shortly after the 2.0 release is final.

  46. usui says:

    Thanks Mike.
    (I am not so good at English.)

    > you have to make sure the Japanese characters are in the Flash file.

    The font property which I am using is MS UI Gothic. Japanese can be treated. Here.

    Japanese is not displayed in slFR2.0.2.
    preview (used font: MS UI Gothic); Here.

    Then, your action script file was customized.

    // Sets height and width of textbox
    if (w == null) {
    w=300;
    }
    if (h == null) {
    h=100;
    }
    if (txt == null) {
    txt=”日本語表示出来ますか”;
    }
    orig_width = Number(w)+4-Number(pleft)-Number(pright);
    orig_height = Number(h)+4-Number(ptop)-Number(pbottom);

    preview (rename sifr_ja.fla, font:MS UI Gothic); Here.

    Japanese characters are no longer displayed.Why is it ?

  47. Cameron says:

    Thanks Mark – just tried it from IE6. I see what you mean!!!

    Thanks for the help.

  48. Awesome job gentlemen. I’m downloading all this to update the site I’ve got it working in. I’m working on a new site that will use sIFR as well. Revolutionary for web text rendering. And about time!

    I’ve been SO bored with regular CSS text and our limited font selections.

  49. I’m truly sorry if this has been addressed before, but my extensive Google searches have left me clueless.

    Basically, I just need to know if there’s a piece of Javascript that will automatically refresh a viewer’s browser when they change their default text size. It’s not so much a problem for my sIFR, but it would greatly simplify some other issues I’m having. Thanks very much.

  50. Mark Wubben says:

    Usui, you have to put the specific characters you wish to use in the Flash file.

    Daniel, please read this comment.

  51. After testing in IE, Firefox, Opera, I can’t get sIFR to work when put in a subdirectory on the website, as absolute paths seem unsupported; eg: dumping all files in /js/ and changing sFlashSrc to “/js/jaguarjc.swf” (font of my choice) gives me empty screen estate, although the javascript loads fine. Am I doing something wrong or is this due to the flash security model perhaps? changing the path to the url does not work either, for example:

    if(sIFR != null && sIFR.replaceElement != null){
    sIFR.replaceElement(“h1”, “http://www.yoursite.com/jaguarjc.swf”, “#336699”, “#777755”, “#cc3333”, null, 0, 0, 0, 0);
    };

    What this means is because I use templates (trough php) that I have to add the swf file to every directory on the site that uses h1 tags, let alone the lack of caching. It’s great when it works though :)

  52. Sander van Dragt says:

    Will there be future support for multiple hyperlinks within a tag? At the moment I am using ” – “, which sFIR unites into a single link pointing to the category.

  53. Mark Wubben says:

    Sander, well, that should work just fine… perhaps you could post a link to the page you are working on so I can have a look? (If you can’t make this page public you can also contact me via my website.)

    As for the multiple links bit, I’ll let Mike answer that one.

  54. ElRocco says:

    Thanks for the answer Mark.

    I get what you mean but my problem is not that the flash is not printing, it’s that nothing at all is printing… I don’t want the flash to print, i’d like just the plain old text.

    That’s what I can’t seem to get working.

    Thanks!

  55. Momo says:

    sFIR doesn’s work on MAC IE 5.1.4 at all. No replacement and no alternative CSS display.

    There is no display at all :(

  56. Mike D. says:

    Sander,

    1. Absolute paths should work fine. You don’t even need the http: bit. Just do something like this “/directory/file.swf”.

    2. Not sure what you mean about the multiple links. That should work fine. Perhaps you are referring to using the hovercolor or hoverunderline feature with multiple links? *That*, doesn’t work because of an avoidable limitation in Flash. You can still use linkcolor to differentiate your links from your text, but unfortunately hovercolor and hoverunderline turns the whole Flash movie into one big button.

    Others:

    1. Printability of sIFR: Your normal browser text should print… not the Flash (if you have your CSS and print CSS set up correctly).

    2. Mac IE: Uhhh, that browser is deader than dead, but it should still work. We’ve tested it in the past and it worked fine. Regardless, you can always disable for Mac IE. In the meantime, I’ll look into it.

  57. usui says:

    Thanks Mark.

    I was able to understand gradually.

    Sincerely,

  58. Shecky says:

    Hi —

    Lest you think I’m an ingrate, sIFR **rocks**! I’m integrating in my first major project now, and it’s fantastic. Thank you so much.

    But…it appears that newline (BR tag) support is not working — or at least I can’t get it to. (Nor can Mr. Mark Broad, back at comment no. 19.)

    I’m using the very latest Flash and JS files (the 12/6 @ 12:55pm version). I’ve tried it with 3 different fonts — so I’m pretty sure it’s not a font-specific fluke. Also tried various browsers on both WinXP and OSX.

    I’ve tried BR tags XHTML style, both with and without a space before the slash. Also olde-school style with no slash.

    I tried modifying line 248 in sifr.js to use \r instead of \n, and also both of those together.

    Alas, none of this has worked. Rather, it just makes the area occupied by the Flash larger — which makes sense: new lines = taller area. But the font simply enlarges and the line breaks per se do not appear in the Flash-ified text itself; just a space.

    Anyone have any ideas? Thanks!

  59. Mark, I’m sorry to have missed that comment. Thanks for the quick answer. As it turns out, I figured out a pure CSS workaround that’s much more elegant anyway. (It’s a centered column defined in ems and has a background that scales in all four directions, if anyone’s interested).

    The sIFR works great, too.

  60. Marcus says:

    Nice update, but Opera and Safari still show a green area if the background is set to transparent. Can this problem be solved in a future version?

  61. Mark Wubben says:

    Shecky (and Marc Broad), it could be that when you have a newline inside a link the Flash doesn’t render it. (If I’m not mistaken Mike is looking into this.) If you are indeed using the newline inside a link, let us know if it works without a hover color. The hover color requires a different Flash behaviour which might also be causing the problem.

    Marcus, Mike and I agreed to creating a fallback mechanism for transparent backgrounds. Could you tell me in which Safari and Opera versions the problem exists? I’ve also spotted this problem in old Gecko builds, so I’ll be having a good time figuring that all out :)

  62. Greg Kaufman says:

    The sIFR technique is fantastic — a wonderfully extensible method to enhance any site, easily upgradable and ultimately providing an easy way to dynamically render Flash content on-the-fly.

    The personal Web site I maintain at http://www.gregkaufman.com will soon use sIFR 2.0 throughout the www page, obviously focusing on titles and similar text.

    As I think towards the future and my wish list for sIFR, the two features I am most interested in are:

    (1) Dreamweaver extensions to easily and efficiently work with sIFR’ized text

    (2) A plugin for Textpattern to easily render text sIFR-enabled vs standard-text

    //gk

  63. Davies says:

    There is some problem using sIFR with a hyperlink. For example, the text is short but the hyperlink takes up the entire line. Meaning, if I hover over the text and the empty area, it’s still clickable…

    Also, how do I change the Text Size..

  64. Mark Wubben says:

    Davies, that’s because you specify a hover color, which makes the whole Flash movie clickable.

    I’m not sure what you mean by “changing text size”.

  65. Mark Wubben says:

    Greg, #1 is already being worked on, see also comment 40.

  66. John says:

    Can somebody tell me what exactly I need to do to edit the sifr.fla file? I’m using Flash MX 2004 and every time I go to File -> Export Image, my text is tiny and wraps on two lines and says Do not remove this text. instead of being the correct size and text displayed in the header text. When I use the Selection Tool and double click it just shows the size in the properties box, then if I double click it again it starts editing the text and shows the font type. I’ve also tried highlignting the text and selecting my font type but that doesn’t work either.

  67. Julian says:

    RE: Transparent/Green issue…
    My offending browsers are:
    Safari 1.0.3 (v85.8)
    Opera 7.20 (Windows XP)

    BTW: It wasn’t too difficult to hack the JavaScript (lines 338 and 355) to hard code a bgcolor.

    QuickTime Symbol…
    Has anyone else got a problem where the heading is simply replaced by a Quicktime Logo? My client running IE6 on Win 98 is seeing it but I can’t reproduce it. (I have screengrabs – he’s not lying!)

  68. Marc Broad says:

    Mark W, Mike –
    Sorry for the delay in testing. The newline was in a linked element.
    Removing the Hover color did not make any difference.

    Sorry I cant be of any more help (an example can be found @ http://www.greenglobenz.com on the Kaikoura article.

  69. Mark Wubben says:

    Julian, thanks. The background color is an option, by the way.. just replace “transparent” by the color you desire ;-)

    Marc, thanks. Perhaps Mike can figure that out.

  70. Shecky says:

    Mark W. and Marc B. —

    Re: newline support

    In my case, no linking is involved. Just plain ol’ vanilla text, inside header tags (h1, h2, h3). For yucks, I went ahead tried setting the bgcolor to null. Alas: no dice.

  71. Shecky says:

    er…I meant to say hover color, not bgcolor.

  72. Shecky says:

    Please forgive my repeated posting, but I’ve stumbled upon the solution to the newline issue.

    BR tags within sIFR-ized text only work when its style includes display:inline.

    d’oh.

    Thanks!

  73. Adam Weston says:

    I haven’t gotten a chance to try this version yet, but I checked the new code for a line that was causing Netscape 7.1 to throw a “zero quantifier” with RC1. The offending code is still there in RC2, so I thought I would let you know. This line (#320) substitutes %25 for any % sign that is not followed by a digit. Replacing the line with the one below seems to fix it.

    //sText = sText.replace(/%\d{0}/g, "%25");    original
    sText = sText.replace(/%(?!\d)/g, "%25");     //fixed
    

    BTW, Thanks for the awesome tool!

  74. John says:

    Whenever I have multiple h2 or h3 tags, only the text in the first tag appears. I noticed someone else on the previous version had posted this problem and linked to his site at http://testing.h3nt.com/stoerungen/. He said it mysteriously started working but when I go this page in Win XP SP2, Firefox 1.0 none of the code in his h3 tags appear, but they do in IE.

    Does anyone know why and how to fix the problem?

  75. Urban Faubion says:

    I’m having a problem with sIFR and CSS drop down menus. I have a drop down menu built in CSS above an h2 I’m replacing with sIFR 2.0. When the menu drops down, visually covering my h2, everything works correctly. The problem is when I move my mouse down the menu to an item that is over the h2, I loose focus and my menu disappears.

    Am I missing something or is this a bug?

  76. Jay States says:

    I wanted to tell you that sIFR is broken in the new developers version of Safari 1.3. I don’t have a preview version of Safari 2 on OS X 10.4, but I’ve heard that it’s the same version as 1.3 for OS X 10.3(minus the RSS feeds)…. I’m not sure on how to fix the problem…. but I thought I should tell you about it.

  77. Mark Wubben says:

    Adam, interesting. Netscape 7.1 is based on a fairly recent Gecko build, so I’m not sure why exactly this breaks… will have to get an old Mozilla version and see for myself. Anyway, thanks for the fix!

    John, I have no idea what is causing this. The site works just fine in my Firefox and IE.

    Urban, I’m not sure. What about a testcase?

  78. I’m having a problem with sIFR text ON a background image. Actually, the text itself doesn’t go over the background image, but since the sIFR box fills the whole horizontal space it’s in, I have a problem with it covering the background.

    I first used a transparent background, but on Safari, when you move the browser window a little, the sIFR text gets all pixelated. If I use a background color, it of course, partially covers my background image beneath. If I don’t specify a background color or any transparency, I have a white text box.

    Hmmmm… Ideas anyone?

    Demos here:
    With background color covering background image but NO pixely text – http://kpcinc.com/bc/bc01_new.htm
    With transparent background … move your window … watch the text pixelate – http://kpcinc.com/bc/bc01_new2.htm

    And disclaimer – I did NOT code this site. I am only sIFRizing it. And I’m aware there is an incomplete doctype. But if you put in a complete one, the page falls apart. I am leaving it right now. :)

  79. Mike D. says:

    Jay: Thanks for the heads-up. I just got the latest Safari build from the Apple Developer Connection so I can debug. We’ll have a fix for this before it is released… it’s some sort of weird js error.

    Stephanie: Yeah, that’s one of the many reasons why I wouldn’t recommend using the transparent background feature. Transparency of plug-ins just isn’t very well supported in any browsers besides PC/IE.

  80. Mike, I have a question; At the moment we’re integrating sIFR 2.0 with our wordpress-blog, and it’s going great!, but…

    we noticed that the headers automatically scales the title to the appropriate DIV-width. That means that different titles (long or short) have a different size of the font (small or big).

    Is it possible to make al the headers equal in size?, (to turn of the scaling)

    I hope this makes any sense, my english is not so well,

    thanks in advance, greetings from nijmegen, the netherlands

    Matthijs

  81. ElRocco says:

    Hey there,

    Still having those printing problems…

    Changed some things around. Still doesn’t work (either on Mac/Safari or Firefox or Windows/IE).

    Thought I had found the solution in that my replaceElement calls were located in the sifr.js file while all the ones that I see the plain-text when I print, the replaceElement calls are directly in the HTML. Changed that around and doesn’t change anything.

    Here’s one of the pages where I have a problem :

    http://dap.egzakt.com/products/CE5000/

    The word “Products” in the orange banner at the top is sifrized but doesn’t print at all (like I said previously, all I want is the plain text to print).

    Thanks!

  82. Mark Wubben says:

    ElRocco, set the media attribute on the CSS files which aren’t for printing to “screen”, that will hopefully solve your problem. (I have the feeling that these files are overriding the print rules.)

    Matthijs, I’m not really sure what you mean, but that could also be because I’ve spent the entire afternoon learning for my Latin exam which I have tomorrow…. don’t you just love the Dutch school system either? ;-)

    Oh, about the newline issue, I forgot to write about that yesterday. Turned out to be silly bug in the JavaScript… no idea how it got in there, but it’s been fixed anyway. Hopefully I’ll find some time this weekend to roll in the latest changes, and then…. we need some more testing!

  83. Mike D. says:

    Matthijs: See the paragraph on “font tuning” in the documentation. That is a necessary step and it will solve your scaling issues.

  84. ElRocco says:

    Thanks Mark!

    Printing problem resolved!

  85. John Winkelman says:

    Hi All.

    This is what I see in Firefox1.0/Win with the Flash 7,0,19,0 plug-in:

    screen shot.

    Lots of headlines missing. The Flash movies are in place but, obviously, no text. The same thing is happening on one of our projects.

    Anyone have any suggestions for fixing this?

    thanks,

  86. Mike D. says:

    At the risk of sounding preachy, please thoroughly check your implementations before asking for technical support. 95% of the time someone posts a problem it is because they copied something incorrectly (like a media type in a stylesheet or a class or something like that).

    I don’t want to discourage bug reports because we have gotten a lot of great ones over the last few months, but really, most implementation problems are just that: implementation problems.

    And if you’re going to ask for help, which is just fine, nobody can help you without a URL. Screenshots do not provide any insight considering most problems are coding problems.

  87. John Winkelman says:

    Apologies for the above post (#88). Please ignore.

    I re-started Firefox, and Guess What?

    Everything worked.

    Argh™

    I suspect the ghost of another site occasionally stays resident in Firefox memory space, and it b0rks things which would otherwise work just fine.

    That having been said… excellent work, sIFR crew!

  88. Cheshire Dave says:

    Well, with something this complicated to implement, sure, there are going to be implementation issues. But for those of us who aren’t quite as knowledgeable about the dark arts of CSS and how it communicates with a Flash file, it’s hard to know what’s an implementation issue and what’s a bug (or at least something that would be tough for someone with only a basic working knowledge of CSS would be able to sleuth out for him- or herself).

    Anyway, to my problem: at this point, I can’t get Mac IE 5.2 to either render the Flash or degrade to CSS (as in post #56, there’s just nothing) without doing something that then breaks sIFR’s consistency:

    Example 1

    Oh, and in addition to IE 5.2 Mac not showing anything (IE 6 Win shows sIFR), IE on both platforms forces a bigger width on my third column, which wrecks my structure, which you can see in the link above.

    Now — if I change the beginning of

    .sIFR-hasFlash h1 {

    to

    html .sIFR-hasFlash h1 {

    (note the space between “html” and “.sIFR”)

    then all of a sudden IE Mac 5.2 degrades gracefully to CSS, but in every other browser I no longer have consistent sizing in my sIFR-generated headlines:

    Example 2

    I have tinkered with font-size, line-height, and letter-spacing over and over and over and over, but nothing I do makes a difference. It may indeed be an implementation issue, but does anyone have any ideas?

    For Matthijs — I had a similar problem. It just takes quite a lot of tinkering. In my case, I was trying to use the letter-spacing property to tighten the tracking because the font I’m using looks too loose as its default, but I didn’t realize until later that in the world of sIFR, letter-spacing doesn’t affect tracking (or at least I haven’t seen it make any changes). I had kept using negative values, but in fact a positive value was more effective. If it’s helpful at all, I used equal values for font-size and line-height, and a slightly larger value for letter-spacing, and that seemed to do the trick.

    I love the promise of sIFR, but if I can’t get IE to play nicely, what’s the point? There are still enough people who use it for this to be a problem. I don’t have the luxury of not caring about those users.

  89. Citizen.K says:

    When i upgraded from sIFR 2.0 RC1 to RC2 i recognized a strange thing: The background tiles on some of my sites did not work properly in IE 5.01 and IE 5.5. – instead, the background apears black.

    I resized the tiles from 5px width and respectively from 5px height to 25px in height/width. This is the minimum size required to work properly for one website, but not in every case. Some tiles (e.g. in the sidebar) do not show up at all. When i switch back to RC1, everything works fine again.

    Any suggestions for this problem?

  90. Mike D. says:

    Not exactly sure what the problem is Dave, but I can tell you that the value you’re using for letter-spacing in your decoy style is probably way too big. Remember, your goal in the decoy style is just to get the browser text to take up about the same space as the sIFR text. 15 pixels of letter-spacing between each letter would only be necessary if your Flash font was much wider than your browser font. It looks to me like your Flash font is about the same proportions as your browser font so you shouldn’t really have to do much tuning at all. Maybe just fractional letter-spacing values (letter-spacing: -.2px, etc, etc). I noticed you are also changing your font size from 16px to 12px in your decoy style, which probably isn’t necessary either, unless you want much bigger browser text than Flash text.

  91. Cheshire Dave says:

    Thanks, Mike — ok, more fiddling showed that the excessive letter-spacing was the culprit with IE messing up the third column, and taking out font-size and boosting line-height got me the same result. Cool.

    And I seem to have discovered the solution to the main IE 5.2 problem. Since IE works when you use “html .sIFR-hasFlash” but Firefox and Safari start to bug out, you can have two declarations, one with “html .sIFR-hasFlash” and one with just “.sIFR-hasFlash” — just make sure the second one is commented out so that IE ignores it, like so:

    html .sIFR-hasFlash h1 {
    visibility: hidden;
    line-height: 24px;
    letter-spacing: .1px;
    }

    /*start iemac hide \*/
    .sIFR-hasFlash h1 {
    visibility: hidden;
    line-height: 24px;
    letter-spacing: .1px;
    }
    /*end iemac hide*/

  92. Cheshire Dave says:

    Not that I figured out on my own how to fool IE; I got that method here.

  93. Mark Wubben says:

    Matthijs, yup :)

    Ceshire Dave, ah, thanks. The marvels of IE/Mac, eh?

    Citizen.K, please read this.

  94. Eric Curtis says:

    Thank you for all the work. This tool has great potential in alot of my work. In a test run I made I used Eurostyle Exteneded Bold 2 and was somewhat dissappointed in the antialiasing. I tried exporting it out as version 7 and saw no improvements. Are there any suggestions for improving this? Perhaps it is just the font…

    Sincerely,

    Eric C

  95. Mark Wubben says:

    Eric, I don’t know the font, but due to the scaling technique (or the nature of Flash?) the scaling of bitmap fonts doesn’t work well.

  96. jankowski says:

    Are the DOM element style accessing functions available in javascript so horribly non-cross-browser that detecting color, link color, hover color, background, padding, etc MUST be done by passing them in?

    It seems like describing your visual styles in one place (your already existing css), and having them applied either to the document text by the browser or to the flash text by sifr is the more elegant way of doing things…

    (Editor’s Note: In a word, “yes”. You cannot access style properties from a stylesheet using javascript in browsers which don’t support getComputedStyle… hence the reason why things are coded this way)

  97. There is no control above the sizes and intervals… Here”>http://eds-soft.com/rus/support.php>Here

  98. Mark Wubben says:

    Virtor, what do you mean?

  99. Will Chatham says:

    Looks cool – but what is it?

    I found this page from the WaSP’s recent blog entry but nowhere can I find a description of what sIFR is or does, not even in the readme file. Can you explain?

    Thanks!

  100. Mark Wubben says:

    Will, sIFR replaces HTML elements with Flash files, so you have much better control of the typography your website uses. Your website will still be accesible as well!

    (As you can see this is RC2, there have been several older versions already, we don’t explain with each new version what it is all about anymore…)

  101. Lou Vanek says:

    Nice work. A couple comments.

    I didn’t like the way sFIR was resizing my headlines so I just commented out the flash width params and I get consistent font output now. Easy fix.

    What I’m not sure about is if it’s possible to add alpha to the text. I’m new to Macromedia MX but I know flash supports alpha because I’ve used it with Ming and PHP/SWF Charts. Anybody know if it’s possible with sFIR? This is already a cool hack, but alpha would be bitchin.

    Once again, kudos!

  102. Penar says:

    Hey guys,
    This stuff is fantastic!
    One small issue though: I sticked closely to your code, and all is running well in Firefox…alas IE doesn’t dig it (it’s all empty). The URL is here http://www.peshkupauje.com/index-new.html

    I know people shouldn’t use IE, but most of my readers are people that use public computers, where they don’t have a say in what browser is used.
    Thanks again!

  103. Adam says:

    I have finally implemented sIFR on my first Website and am very pleased with the results on IE/Win & Firefox but for some reason it crashes on IE/Mac although Netscape and Safari are fine.

    If anyone could perhaps point out where I am going wrong I would be very grateful.

    http://creativefreedom.co.uk

  104. Mark Wubben says:

    Lou, could you elaborate what exactly you removed? The CSS properties or something in the JavaScript code?

    Penar, I think this is because the path to the Flash files is confusing IE. Try /georgia.swf.

    Adam, I think this is a CSS issue, but, without more information on what you mean by crash, I cannot be sure, of course.

  105. Lou Vanek says:

    I changed this line:
    //sVars = “txt=” + sText + sFlashVars + oContent.sLinkVars + “&w=” + sWidth + “&h=” + sHeight + oContent.sLinkVars;
    to this:
    sVars = “txt=” + sText + sFlashVars + “&h=” + sHeight + oContent.sLinkVars;

    I changed this line:
    //nodeFlash.style.width = sWidth + “px”;
    to this:
    nodeFlash.style.width = “100%”;

    This stops the funny font scaling.

  106. Adam says:

    Mark,

    Thanks for the feedback. I’m a bit new to CSS so it is of little surprise it is an issue with my code rather than sIFR.

    By ‘crash’ I mean that the browser hangs with the coloured wheel spinning ad infinitum. It does manage to load all of the visible page including text, bg colours and borders, but no images and no sIFR (or replacement text) seems to load before it ‘hangs’.

  107. Penar says:

    hey mark,
    thanks for the immediate response. I tried /georgia.swf…no change. I also tried full address, still no headlines in IE (everything is fine in Firefox, Win for both). did anyone else ever encounter a similar issue?

  108. Mark Wubben says:

    Lou, could you put up two test pages with the hack applied and without? I’m curious as to what actually is the problem and if this is the right solution. I have to say though that I’m not really up to speed with how Flash calculates the font size, so I’ll defer to Mike on that.

    Adam, curious. The tests Mike did with IE/Mac didn’t gave any trouble, but from past experience I know it’s usually CSS which messes things up. Perhaps Mike can have a look.

    Penar, I’m getting a JavaScript error in IE this time (was at a different box earlier today). It could be that other JavaScript code is causing the problem, so if you could try to determine that, that would be great.

    (IE’s JavaScript debugger is really quite bad, and I don’t have any other debuggers installed at the moment, so I can’t verify this for you.)

  109. Lou Vanek says:

    You can see an example of what I mean at,
    http://www.123schedule.com/home.aspx?scalefont=true

    and you can see how my javascript change affects the same page,
    http://www.123schedule.com/home.aspx?scalefont=false

    Especially notice the menu item “Registration,” (half way down the
    page) the way it is being scaled small with the default javascript.

    BTW, I’m not suggesting you incorporate my hack into your work.
    I’ll I’m saying is that this works for my site.

  110. Mike D. says:

    Lou: The fonts on both of those pages look exactly the same to me. Although, the rest of the layout looks severely out of place. I get one column of text down the middle of the screen and then I get three columns, including the navigation, below that column. Safari 1.2.

  111. Lou Vanek says:

    I haven’t tested with Safari, so I couldn’t say. Wished I owned a (recent) mac but I don’t. In Firefox1.0-windowsXPsp2 and IE6 the menu items are being scaled to fit, and the scaling is uneven and noticable on WindowsXP. Maybe I’m too much of a stickler for detail, but it bothers me.

    As to the the one column of text down the middle and everything else
    down below, well, that’s the way it’s supposed to be ;>

  112. Penar says:

    Thanks Mark,
    I figured it out…the problem in IE was that the text that would be replaced was within a table…so I got rid of all the tables on the site (should have done this a long time ago) and it works fine. THX!

  113. Mark Wubben says:

    Lou, hmm, I figure the dimensions of the elements sIFR should replace are a bit off (perhaps the table has it’s influences?).. or perhaps sIFR renders larger with your hack applied. Try to use the decoy styles to increase the font size.

    Penar, come to think of it, I’ve heard of that problem before. I wonder why the replacement isn’t working though. Do you still have a the table version somewhere so I can test?

  114. Mark Wubben says:

    For anyone who is reading this far down, I just put up some new stuff about sIFR:

    1. Where to Replace
    2. More Opera Testing
  115. Adam Weston says:

    Does anyone know a way of having supertext or subtext in sIFR? I know it’s not currently supported, just wondering if anyone has any thoughts on a possible way to do it.

  116. Mark Wubben says:

    Adam, in theory that could be done by using the sub and sup elements and sending them to the Flash, but because of the different size and position of the text in these elements the scaling might become a lot more difficult. Let’s hear what Mike has to say about this.

  117. Hi. I would like to use sIFR with the Romanian-language characters ă, î, â, ş, ţ.

    Of these, just î and ă are supported in the Latin-1 character set. I have gone to Flash Character settings and told it to export the characters ă î ş ţ â, and â and î are working perfectly in sIFR headings.

    However, the ş and ţ characters, which are supported by Unicode, do not show up at all. Does anyone know how to add Unicode support to sIFR.

    Thanks!

  118. Jonas says:

    o.h. m.y. g.o.o.d How much have I been waiting for this?? Thank you a lot! This will change how I can create html based web sites forever!

  119. Mike D. says:

    I am closing this thread because sIFR 2.0 is now out. Read about it and download the new files here.

  120. sIFR 2.0 is here!

    sIFR = Scalable Inman Flash Replacement

  121. Washout 2.0

    Winter is officially here, It’s been snowing on and off since December 1st this year and around 5 – 10…

  122. sIFR reintroduces typography to sites with dynamic content.

    Mike Davidson: sIFR 2.0: Release Candidate 2 is Finally Here…

  123. FatMixx says:

    this is a good thing?

    Urgh, so now I know where the flash headlines on ESPN.com come from. I know that I’m a measly engineer and programmer and miss the beauty of great typography and fancy fonts. And Mike knows of my undying love for flash. So it won’t shock him that …

  124. SFist says:

    SFist Cheshire Remembers 2004

    Like SFist Emily, I’m bad at lists. So I’m just going to relish the chance to write in the first person singular for a moment and break down the highlights and lowlights of the year for me, in no particular order: Best Moment of the Year My Life: Gett…

  125. waveform says:

    Der Blick in die Glaskugel – Webdesign 2005

    2005 wird viel neues und vor allem viele Veränderungen bringen. Das meint zumindest Forty Media. Nachfolgend die kommentierte Hellseherei……

Comments are closed.

Subscribe by Email

... or use RSS