Question

Why do designers use sIFR if they can use @font-face ?

What is wrong with @font-face ?

@font-face {
    font-family: "Hacen Tehran_eot";
    src: url('Hacen Tehran.eot');
}

@font-face {
    font-family: "Hacen Tehran_ttf";
    src: url('Hacen Tehran.ttf');
}

p {
    font-family:"Hacen Tehran_eot", "Hacen Tehran_ttf", sans-serif;
    font-size:40px;
}

Answer 1

What is wrong with @font-face ?

It’s new, or at least compatible browser support for it is new.

Until very recently, the only browser to support it was IE, and then only with the EOT font format, which could only be generated by the complicated and unpopular WEFT application.

There are still format problems today. Although WOFF is the clear future winner, we’ve still got some recent browsers that need TTF/OTF instead, plus iPhone and its bizarre SVG fonts, and of course plenty of IE<9 browsers that want EOT.

Combine this with the issue of finding fonts whose licences actually allowed them to be embedded in a web page, and @font-face was a non-starter. The licence situation has got much better recently, with plenty of good-quality fonts available for real web embedding.

But still, chances are if you’ve already picked a font, especially from one of the major foundries who are still dragging their heels, it’s not going to be possible to license it. Vector-based replacement techniques like sIFR and Cufon are more like the regular embedding that traditional licences often allow, and image-based replacement techniques don’t need an embedding licence at all.