Typography in Headings: sIFR? Image Replacement?

Posted: May 28, 2007 Comments(15)

One of the more common areas for designers to apply a custom font to a design is in the site headings. It is in their nature to stand out, making an attractive target for a custom type face. Developers have tried time and time again to come up with the best possible image replacement techniques to ensure that their documents retain proper accessibility while reaching the next level. A new and exciting method to obtain custom type became available and lots of people loved it; sIFR. sIFR gave designers an unobtrusive way to include any font under the sun in their designs, opening new doors for Web design. While sIFR has garnered quite a bit of attention and support, I have yet to see it implemented all that often.

A short history of custom type on the Web

We can all remember back to the days where finding bits of information about font requirements were found next to the screen resolution requirements as well as browser requirements. Many times, the fonts were supplied with a quick hyperlink and after a quick download, unzip, installation, and restart of your browser you were ready to go! Luckily, providing a requirement such as that seemed to be short lived (although you still run across the issue as well as browser and resolution requirements to this day). With the implementation of CSS, developers and designers had much more to work with and were now able to use more effective techniques in their designs.

CSS based image replacement

Using CSS image replacement caught on like wildfire and many designers use it in nearly all of their work. Personally, I find myself using the technique at least once in nearly every project I work on, including this website. There are many different methods used for image replacement, each with their own set of pros and cons. A great resource to read about and view examples of various techniques is a post on mezzoblue entitled Revised Image Replacement. A number of methods are detailed including a short description, code sample, and live examples of each.

During the second revision of this website, I had come up with a technique for image replacement that I hadn’t seen anywhere else. The details are included in the write-up, but essentially it was the best way I could find to not bloat the code with extra markup while retaining accessibility as best as possible. Instead of trying to hide any of the content in the first place, I attempted to camouflage it using the color of an image. Please read more about my latest take on image replacement.

What is sIFR anyway?

As taken from WIKI.NOVEMBERBORN:

sIFR (or Scalable Inman Flash Replacement) is a technology that allows you to replace text elements on screen with Flash equivalents. sIFR is the result of many hundreds of hours of designing, scripting, testing, and debugging by Mike Davidson and Mark Wubben. Mike, Mark and an invaluable stable of beta testers, supporters, and educators like Stephanie Sullivan and Danilo Celic of Community MX completely rebuilt a DOM replacement method originally conceived by Shaun Inman into a high quality cross-browser, cross-platform typography solution for the masses.

In my opinion, sIFR is, in and of itself, quite a good idea as well as an evolved technique. Earlier versions of sIFR became available some time ago, and it is still being researched as well as developed to this day. The new beta releases are including new features, as well as rethinking implementation itself. My main question is: why is sIFR not more widely implemented? Is it because of the requirements placed on the reader in that they need to possess a third party plugin as well as have JavaScript enabled to run a check for that plugin?

While requirements placed on the reader may be slightly overbearing, sIFR was developed in such a way where it will gracefully degrade for your readers. Am I mistaken in my observation that sIFR is not implemented as much as you’d think?

In closing

As with any story, there are two sides with both CSS based image replacement as well as sIFR as choices for custom type in headings. There are accessibility issues attached to image replacement, and user requirement issues when dealing with sIFR. Which do you think is the better choice and why?

P.S. I’ve ended posts with questions before in hopes of getting some opinion from readers as I value their opinion. I’m hoping that those of you who don’t normally write a comment after reading the article can find a few minutes to do so on this. I’m truly interested in the reaction other designers and developers have regarding the two techniques. Thanks a lot in advance!

Get my newsletter

Receive periodic updates right in the mail!
  • This field is for validation purposes and should be left unchanged.

Comments

  1. I think sIFR is awesome, and I decided to use it on the latest version of my site. Depending on the project, I think it’s totally worth using for headings and such, and definitely increases the richness of typography on a site.

  2. I’ve never really been a fan of sIFR. But to be honest, I can’t say I’ve put much time reading up on it either. In most cases when I’m going to use image replacement, it’s because the heading has a background or pattern to it as well as a non-standard font. In which case, as far as I know, sIFR wouldn’t help in that situation anyway.

    I prefer Dave Shea’s image replacement technique. Funny enough, I actually linked to it in my latest article as well.

  3. I think sIFR and Image-Replacement solve two different problems. I use IR confidently for headings, and have only dabbled with sIFR, but have found some limitations in what I wanted to implement.

    IR is perfectly acceptable for headings, but the limitation is you must know the text for this to work. For dynamic headings, such as in blogs or any CMS, then the IR technique falls down and sIFR should step in.

    Using sIFR itself is an art. I have had some issues with line-height and letter-spacing, which needed a fair bit of tweaking.

    On an upcoming site, sIFR would have been perfect, but in the jQuery version I am using, it does not support text-transform: uppercase which is what I need. I also needed some different colours, and line-breaks, within headings themselves – all this has proven difficult to use the sIFR technique.

  4. I suppose you could call me an sIFR evangelist. I love it, use it for everything, not just headings, but never body content. At my current job I never know when someone will go into a site of mine and change a heading, or a phone number, thus sIFR is really the only solution. I can’t always go back into my PS file and change the text every time this happens.

    I personally have not run into really any major limitations for sIFR, and I’m not even talking about the latest sIFR 3 beta, I’m still using sIFR 2.0.2.

    Although beta looks promising, it’s still in beta, and I don’t feel comfortable using it at a production level just yet. If you need to break headings, but need those headings to be dynamic, set widths so that your actual text does break, thus your sIFR will break as well. Need a fancy font (which sIFR lets you embed 90% of fonts from my experience, and if you can’t embed the font you want, like Adobe Garamond, find something similar like Day Roman) on a patterned background? Use the transparent flash method. Although the instructions say to avoid this method, I test on IE6, IE7, Firefox 2, Opera 9 and Safari whenver I can get to a Mac and have never run into any problems. The only drawback is if you have links within your sIFR (which are also extremely easy) and you’re using transparent Flash, the link will not immediately be recognized with a changing cursor and hover state inside Firefox, but it will within IE. That is a limitation of all transparent Flash though.

    Overall I can’t thank Mark, Mike, Shaun and everyone else who has been involved in sIFR enough. With the curent work that I’m doing, it is a godsend. I go all over the web and see text as images. Even with using image replacement, I can’t just copy and paste that if I wanted to. It just seems wrong to have text on the screen which I can’t interact with, why is it images?

    Bottom line is sIFR is a very powerful tool that allows you to use good looking fonts throughout your site for almost anything, and it retains a semi-natural text behaviour, unlike image replacement.

  5. @Colin Devroe: I’m thinking you’re not alone in your stance. There are a great many designers and developers who feel something like sIFR can be considered overkill for it’s purpose.

    @J Phill: There’s no doubt about that. sIFR can give a website that extra ‘oomph’ and bring a design to the next level. In my personal experience however, I’ve seen implementations that were made for nothing but the sake of implementation. Using sIFR for blog headings makes sense to me as the wording will constantly be changing; not something I’d like to create an image for every time.

    @Matt Brett: I thought that was pretty funny reading your post and seeing the same link. You should definitely keep your eyes on sIFR 3, as that crew is working really hard to make sIFR even more feature rich.

    @trovster: That’s a really great point, and I agree. sIFR can be the perfect fit when it comes to a requirement of dynamics, and CSS based solutions are sometimes a better fit as well.

    @Mark Wubben: Thanks for including the link, keep up the great work!

    @Andrew: Wow! What a response! First and foremost thanks for taking the time to write up your thoughts. I totally agree that sIFR is an extremely powerful tool and I think we’ll be seeing more and more of it as the sIFR team continues to improve it.

  6. From a branding point of view, sIFR can really help to keep consistency across print and web without compromising a great deal on accessibility. It gets a thumbs up from me…

  7. While I agree that it is a cool tool and would be one if the best ever practicable flash tool (along with swfIR). I have seen this tool been used wrongly and hence the outcome was quite horrible.

    The problem accord when the original designer did not take into account what it would look like if Flash was not installed on a browser….

  8. I have played around with sIFR, and I think it’s great. There are a variety of reasons I haven’t implemented it more often (I used it for one site that never launched, plus in isolated places on other sites).

    On one site, after I used sIFR with a fancy display font for the headings, I realized that the font was distracting and using it didn’t add anything…So I took it out.

    On another site, the structure of the CSS was rather poor, and it was going to be a pain in the butt to update it to accomodate sIFR in the right places. So in that case, I would say that you have to plan for it from the beginning (or really write good CSS), and often we designers aren’t lucky enough to work on a site from scratch!

    I’ve also had my difficulties tweaking the settings so that it looks good both with and without Flash, and call me lazy, but I don’t always have the time to get it as perfect as I’d like it to be 🙂 but I’ll have to try out v3.

  9. @Jermayn Parker: You’re absolutely right, unfortunately use and abuse is all too common when it comes to the Web.

    @Matt Davies: I don’t mean to speak for Jermayn Parker, but what I’ve assumed is that the developer didn’t bother to give any style to headings he intended to be replaced with sIFR, which is a mistake made by many.

    @Rachel Maxim: Yes definitely keep your eyes on version 3 — their team is doing fantastic work and sIFR is getting better with every release.

Leave a Reply

Your email address will not be published. Required fields are marked *