sIFR 2.0 Is Almost Ready… Please Test

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

Alright, sIFR 2.0 is finally ready for release! Before Mark and I release it, however, we’d like sIFR developers to run through a short set of testcases over on the sIFR Wiki.

The testcases represent some of the more complicated things that are happening under the hood of sIFR and can be found here.

Since we’ve only added two small things (a tiny Opera tweak and the ability to show browser text while the sIFR text is loading), we don’t anticipate any problems, but these testcases are meant to insure nothing was overlooked.

If you have a free minute, please run through the tests and let Mark or I know if you experience anything out of the ordinary. The whole suite should only take a minute. If every seems to work ok, please also feel free to post a comment on this page saying something like “Win XP/Flash 7 — Firefox 1.0, IE 6, all tests passed.”

Many thanks, and sIFR 2.0 will follow within days.

56 comments on “sIFR 2.0 Is Almost Ready… Please Test”:
  1. Mark Wubben says:

    If you do indeed experience anything out of the ordinary, please clearly describe what you see. If necessary provide a screen shot. We would also appreciate it if you could check for JavaScript errors and the such.

    And finally, of course, we’d like to know on which OS and with which browser version the problem occured.

    Thanks!

  2. Mark Wubben says:

    And in general, could you contact us to let us know in which browsers the tests succeeded? That way we’ll have an overview of what has been tested and what not. I’ll update the wiki if there are sufficient reports for specific browsers.

    Thanks!

    (Mike, could you update the post with this stuff? Thanks)

  3. Adam Slagle says:

    Looks good in Firefox 1.0.2 – both HTML and XHTML.

  4. Daniel Sholler says:

    It looks fine in Opera 7.54

  5. Nic Rodgers says:

    Working fine in IE/Win 5.0 – has recovered from the hidden text problem with RC4.

  6. Justin W says:

    This may be a bit off topic because I’m running a slightly older version of sIFR on one of my client’s sites, but I just havn’t had time to update it and I’m wondering if its the sIFR version thats really the problem or an error on my part. If you look at http://studentsagainstterrorism.org/board.htm in Firefox, you’ll see that the “General Board” header is much larger than it should be, and is much larger than the same header above (the “Executive Board” header). So is this my error or do I just need an upgraded version?

    Thanks!

  7. Adam M. says:

    I’m seeing something in full-page.html that I don’t think is really sIFR-related.

    With sIFR both on and off, one headline contains garbage characters:

    %HELVETICA, & ARIAL IN & ” GROTESQUE + ACCIDENT

    The garbage text doesn’t appear in full-page.xhtml.

    New version seems faster in Opera! Looks good in Opera 8.0b3, with transparency working a-OK.

  8. Adam M. says:

    Justin: Can’t give you any advice on your problem, but very nice design you did there. :-)

  9. Urban Faubion says:

    Adam, the “garbage characters” are in the xhtml and html source.

    Looks good in OS X 10.3.8 Firefox 1.0.2

  10. Mark Wubben says:

    Adam, yeah, those are characters in the document. Also the XHTML version of full-page is not the same as the HTML one, nor are they the same as the demo one you can find here. They are just the test demos I use.

  11. Mike says:

    Mac OS X 10.3.8/Flash 7 – All .html tests passed. .xhtml pages did not display sIFR at all but I’m not sure if this is a Safari limitation or not.

  12. Mark Wubben says:

    Mike, nope, this is intentional. We are relying on a hack which shouldn’t work in Safari in XHTML mode, so until we no longer have to use this hack we’ll prevent Safari in XHTML mode from rendering sIFR.

    By the way, you can now also find me on the #sifr channel on irc.freenode.net. (That is, if I’m online.)

  13. Kara Pastour says:

    Just updated to Firefox vs. 1.0.2 – noticing trouble with the long-uri.html page. sIFR link does indicate an active link, but click-through goes to the same url but with this extension:
    http://tests.novemberborn.net/sifr/
    long-uri-000.html

    Guess I’m not sure what it should be resolving to. That’s the only thing I’ve noticed – all other pages seem to be working fine. :) Kara

    p.s running Windows 2000 (yikes, i know!)

  14. Mark Wubben says:

    Kara, cool, it worked! I originally wanted to add those zeros as a fragment identifier, but that didn’t work. So I created a new file. Only downside is that it messes up the statistics for my site: it creates scrollbars from here to Tokyo!

  15. Sanim says:

    I would test it out, but I do not have Flash, so sadly, I cannot use sIFR.

  16. Adam M. says:

    Some issues from Konqueror 3.2.2:

    • None of the .xhtml pages work, but this seems to be a Konqueror limitation.
    • complicated-selectors.html — #lostworld span.lostfoo shows blank white box
    • full-page.html — “The quest to abolish the serif shall continue.” is surrounded by question marks instead of quotation marks.
  17. Kevin Navia says:

    All seems running well from the tests, using Firefox latest nightly…

    Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b2) Gecko/20050329 Firefox/1.0+

  18. Mark Wubben says:

    Adam, do you see plain text in Konqueror in XHTML pages? Those other two bugs are really odd, gotta reboot into KNOPPIX and see what that’s all about…

    Kevin, thanks.

  19. Calrion says:

    Great work guys, can’t wait for the release!

    Test suite looks good to me: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.7.5) Gecko/20041110 Firefox/1.0, Flash 7.0 on Windows XP Pro SP2, 1400×1050.

  20. Great work so far – thanks a lot for giving us back the possibilities of typography we missed so much! :-D

    There’s some minor issue I have on my site (http://www.universaldilettant.net/): In Firefox (1.0 through 1.0.2), the position and text size of some sIFRed <li> elements changes when I reload a page. This happens consistently (execpt when I force Firefox to bypass the cache via Shift-Reload), but only in Firefox – the other Browsers are fine.

    Is this a sIFR issue, and if so, can you do something about it?

  21. Don says:

    typo in the test pages …

    On the first page …
    Please note that in newer Safari versions the XHTML versions do not work. This is an *intented* behaviour.

    and on the first link:
    All seven elements above should be sIFR Elements. If this is not the case, please let Mark Wubben know in which browser this *happend*.

    As I don’t have a clue how to tell if something is a sIFR element or not … I guess I’ll leave the rest of the testing to the more informed users.

  22. Adam M. says:

    Mark: Regarding the xhtml failure in Konqueror, the pages don’t display at all. I got a dialog box asking me what I want to to with the document, and I chose to open it in Konqueror. I then received an error message saying that I’d tried to assign a MIME type to Konqueror — application/xhtml+xml — that it wasn’t capable of handling.

    After reading what Don said about Safari, I suspect this may be a KHTML “feature.”

  23. Mark Wubben says:

    Adam, it seems Konqueror ain’t capable of handling true XHTML then.

  24. Mel Hogan says:

    When exporting the sifr fla on a MAC, none of the .swfs produced work on any browser. I’ve done this w/o changing anything code-wise except for the .swf the javascript is referring to. Any help on this would be appreciated. I’m using flash mx 2004 professional.

  25. Mel… are you saying that your .swf files are blank when exported?? Have you tried using Danilo’s extension at Community MX? (It allows you to export more than one font at a time, but it also gets rid of the possiblity of not doing something properly in the fla when you export. I know I messed it up the first time. :))

  26. Mark… I’m viewing on a Mac in Firefox 1.0 — the “full-page html” says “The The Gothic Times” at the top…. I’m guessing that the extra “The” is intentional… but though I’d mention it. ;)

    http://tests.novemberborn.net/sifr/ua-properties.html — the ua-properties pages simply give me information but not verbiage about what I should be seeing there. This is, perhaps, diagnostic?

    Also, there are two extra characters, missing in your version, in my test of uri-encoded-entities… Pasting mine in here:
    I have: sifr_url_0=#Hell%25F6+W%25F6rld?foo=bar%2526hello=world

    AWESOME work Mark! This will be really fun to present at TODCON next month. I’m excited. :)

  27. Mark Wubben says:

    Stephanie, it should say The Gothic Gothic Times… Those UA properties are diagnostic, yes. Can’t really predict what they should be either ;-)

    As for those extra characters, do you mean %2526? That’s just the escaped version of &.

    Let me know how it went at TODCON!

  28. It does say “The Gothic Gothic Times” this morning. Perhaps it did yesterday as well. LOL

    Looks like all is well then on this end. I am likely to be picking your brain before I leave, so beware. ;)

  29. Henrik Feldt says:

    Hello,

    First of all I get a “bad gateway error” when I click the link provided in the article,
    second I have exactly the same problem as Justin W has. Sometimes the box becomes way too high resulting in a very large heading. I had this problem on my site when I installed sIFR, and I solved by setting a height to all h6 elements. (Which isn’t the best of solutions)

    Other than that, good job.

  30. Mark Wubben says:

    Henrik, appearantly the wiki process got itself killed. I restarted it now. Thanks for letting me know!

  31. Henrik Feldt says:

    You’re welcome ;)

    I did the tests.
    FF 1.0.3 @ Win XP with quite many plugins and extensions

    There was no errors…

    But a few questionmarks:
    1) http://tests.novemberborn.net/sifr/fragment-identifier-bug.html
    no #foo appears anywhere, even after clicking a few times. not in IE6/win either.

    2) http://tests.novemberborn.net/sifr/full-page.xhtml – you haven’t actually added any apersands, questionmarks or plusses to this page…

  32. Mark Wubben says:

    Henrik, it could be that your IE/Win doesn’t suffer from the bug. Mine does, though. It’s a bit odd. As for the full page in XHTML, yeah, that is still the original one.

  33. Jamie Poitra says:

    I’m curious why there is a problem with new versions of Safari. Is this something that you will be attempting to fix or is it something you will need to rely on the Safari developers to fix?

    (Editor’s Note: What problems are you referring to? There are none that I’m aware of.)

  34. Mark Wubben says:

    Jamie, I think you mean the XHTML documents, right? We use a hack to get sIFR working in Safari which is not supposed to work in XHTML documents. Right now it does so, but if that stops working we’ll be in trouble. So… we’ve disabled sIFR for Safari in XHTML mode until we don’t have to use the hack anymore. And in that scenario only people who are using XHTML documents need to update. It’s the best solution.

  35. Adam M. says:

    Mark said:

    We use a hack to get sIFR working in Safari which is not supposed to work in XHTML documents. Right now it does so, but if that stops working we’ll be in trouble. So… we’ve disabled sIFR for Safari in XHTML mode until we don’t have to use the hack anymore.

    Does this mean that Safari fails on all documents with the .xhtml extension, or only those served with the application/xhtml+xml MIME type?

  36. Mark Wubben says:

    Adam, quoting from the source:

    bIsXML : document.contentType != null && document.contentType.indexOf(“xml”) > -1,

    So we’re looking for xml in the MIME type.

  37. Jamie Poitra says:

    Mark,

    Yes that is what I was referring to. I was confused since I have visited lots of sites with sIFR that are written in XHTML never having a problem and was considering using it for my next redesign. My main browser is Safari so the idea of not having sIFR work for but working for nearly everyone else wasn’t cool.

    If it is just looking for the XHTML in the mime type then it really isn’t a problem. Especially since I can’t include that and have IE 6 handle the page correctly anyway.

  38. Julian says:

    I’d like to use sIFR for a CMS project. Unfortunatly, the WYSIWYG editor inserts a couple of spaces at the start of each block level element to faciliate indentation in the code view.

    Suggestion: Leading and trailing white-space in block level elements should be stripped by the sIFR library as it is not significant in html.

    We’ve been able to hack this by applying a reg expression to the return value of the fetchContent function.

    Love ya work.

  39. Julian says:

    For those of you who like to chase down every last pixel. I recommend adding a little extra CSS:

    embed {
    vertical-align: top;
    }

    This will make movie sit inside it’s parent element snuggly and consistantly between ie and firefox.

    (This is the same fix commonly applied to images in mastheads.)

  40. Mark Wubben says:

    Julian, as far as I know sIFR treats whitespace in the same way as the browser does. And since the browser also shows the whitespace (at least, it should show it) I think the behaviour of sIFR is correct. I think you should use that hack and leave it at that (or change the CMS, but that’s probably a lot harder to do).

    Thanks for the CSS suggestion.

  41. Ezku says:

    Whoa. Have you done some repairs lately? For some mysterious reason, my ad blocker no more catches the current version.

    I’ve been experiencing some strange problems with sIFR on my site; with Opera and Firefox it works perfect if I look at it (the files were on my local server), but IE shows regular text. I then asked a guy to take a look at the layout and he told me there were empty spaces where the headers should’ve been – he was using Opera 7.54. Could this be about me using content negotiation to provide an XML declaration and an XHTML 1.1 doctype for proper browsers and just an XHTML 1.0 doctype for IE?

    I have absolutely no ideas as to how to approach this problem. Argh. Help. :)

  42. Ezku says:

    Oh, and the test cases work just perfect on Opera 8b3 /WXP.

  43. Mark Wubben says:

    Ezku, the FlashBlock guys added some CSS to the extension which hides the Flash but shows the text, perhaps that’s what you’re seeing.

    It’s funny you mention this about IE, somebody in the forum reported this problem as well. As far as I know it’s because VBScript is disabled or because the wrong Flash version is used (or there is no Flash installed). Could you be a bit more specific about the IE version, and whether or not you see this on other PC’s? In any case, I’m not really worried because the plain text is showing, instead of empty spaces…

    Which brings me to Opera: those empty spaces might be caused by Opera 7.x not repainting if you give it a Flash object, we worked around this by using innerHTML, which fixed things on my system, so I’m not really sure what to do about it. Could you please verify that the Opera is identifying itself as 7.54? (In ua-properties.html it should say nOperaVersion = 7.5)

    My server does not do content negotiation: those XHTML pages are indeed application/xml+xhtml, and the HTML pages are indeed HTML :)

    Thanks!

  44. Ezku says:

    According to some studying I did on my IE6’s behaviour, it may just be some flaw on my end.

    A friend of mine was running on WXP SP2 and could replicate the aforementioned Opera problem, this time with version 7.52 – nothing showed up. For him, only Firefox worked fine since IE displayed a wrong background colour. I tested with both a transparent and a defined one.

    Why, isn’t this disturbing. I really have no idea whether I can actually use sIFR in this project or not. For me it works as supposed, but…

  45. Ezku says:

    Argh. We just went through the whole thing and found out that the test cases worked perfect in all of his browsers. So it’s either a thing with my implementation, something about the older sIFR version or both.

    Just release already! :)

  46. Ezku says:

    Alright, so it appears that sIFR does the hasFlash-replacement, which hides h3 elements due to the css stuff, but text replacement never actually takes place so the spaces end up being empty. I redid the whole XHTML & CSS shebang, and tomorrow (uhm… 04:18 AM, I guess that’s today, then) I’ll get to see if it had any effect.

    I recommend you ignore me, I bet this is just me being a klutz again and has absolutely nothing to do with sIFR. :p

  47. Mark Wubben says:

    Ezku, hmm, confusing :) I’ll download Opera 7.52 though, to see if I can reproduce the problem.

  48. Mike says:

    Tested using Safari 1.3 on Mac OS 10.3.9

    The only thing I noticed on the updated test pages was the hand cursor not always showing up when the sIFR elements were links. Other than that everything else worked perfectly.

  49. dru says:

    Any idea how much longer until you release?

  50. Mike D. says:

    dru: we’re just working out some possible Safari 1.3/2.0 quirks which may affect a small percentage of installations… after that, we’re good to go!

  51. Ted N. says:

    Are we there yet? Are we there yet?

  52. Mike D. says:

    Ted: Yep, we’re there. We just got there tonight actually. I still need to write up the official blog entry for it, but 2.0 can be found by hacking the filename of the download on the RC4 page. Otherwise, I’ll have an official entry ready tomorrowish.

  53. Yep, we’re there.

    Yay! I’m really looking forward to the improved compatibility.

  54. Andy says:

    Beautiful work you guys,
    thanks alot for making me smile!

  55. Mike D. says:

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

  56. Il test del sIFR

    Per concludere con la serie degli acronimi: sta per uscire la versione 2.0 del scalable Inman Flash Replacement(SiFR) [documentazione ufficiale ; articolo in italiano] , la tecnica in Flash, Javascript e CSS che sto utilizzando per i titoli di questo …

Comments are closed.

Subscribe by Email

... or use RSS