What are cons to use Cufon? Is sIFR still good opt

Question

What are cons to use Cufon? in term of Web Standards, Accessibility and Performance.

I think if we need smooth text than sIFR is still best with screen reader compatibility.

With @font-face font doesn't look smooth like Cufon and Sifr. but Cufon use canvas tag for each letter which it maked harder to read for screenreaders.

To make font smooth is sIFR still best and accessibility compatibility solution?

Is it possible to get Anti-aliasing like Image, sIFR and cufon with using @font-face?

Answer 1

The best solution is to use @font-face. There are already fail-safe solutions for @font-face. sIFR and Cufon:

1. make it hard or even not possible to select/copy text
2. stop working when js is disabled

Look at the Fontsquirrel's font-face generator for a fail-safe solution.

The jagged corners are mostly caused by the operating systems font API. If you really do need to have smooth cornered fonts, instead of relying on js/flash, I'd suggest generating images on server side and with proper alt tags.

Answer 2

I've just done a lot of research on this subject myself. Having smoothly-rendered text is important to me. I'm sticking with sIFR--according to Google Analytics, the vast majority of the visitors to my web site have Flash-enabled browsers so I know that my text will look good for them. And, sIFR is totally fine with SEO and text readers. (It's also selectable too if that's important to you.) If my visitors are using an iPad or iPhone, I'm good there too because Apple products render text beautifully and I'm content with the current selection of web-safe fonts for smaller text on my site. (For larger titles, I use image-baed text with alt attributes.) If Cufon only allowed for justified text, I'd go with that since it's easier to work with than sIFR as well as with javascript animations. (I really wish Cufon would allow for justified text! You can align right, left and center, but not justify--a deal-breaker for me and from what I read, there are no plans to allow for justified text.) One more note--I cannot get sIFR to work when making my SWF font files in Flash CS4--I've asked for help with this on this forum--but it works fine with CS3.

@font-face relies on the rendering engine of the browsers its text is appearing in so it may very well look aliased on Windows machines. This is true of Google Web Fonts and, I assume, of Typekit and similar services. Having image-based text is fine for very brief sentences or words when used with alt attributes, but that's no solution when dealing with large blocks of text--if you want that text to be readable to screen readers and search engines. It's also a pain to edit image-based text too as you have to do it in Photoshop.

For me, the major point of typeface replacement is smoothly rendering text on Windows machines since they're the largest source of traffic to my site. Being able to have any font I can output through Flash is nice too.

I'll implement CSS3 text-smoothing options with web-safe fonts once I'm confident that the vast majority of traffic to my site has CSS3-supported browsers--I'll be watching my Google Analytics data for that.

Answer 3

Unfortunately, there are trade offs among all of these options, and you just have to make the decision based on research. EACH scenario is different. Best rendering? Best load time? EULA issues? Does it need to be on iPad/iPhone? Do you need rapid dev time? Are you willing to put up with bugs?

Personally, I favor @font-face when I can get it -- it's currently the easiest to implement.