Monday, October 27th, 2008

Typeface.js: A potential replacement for sIFR

Category: Design

Thanks to Nexus I saw a new project called typeface.js that offers a solution to typeface management (where you can use any typeface that you want, whether it be on the users system or not) without using Flash (which the popular, oft-mentioned sIFR uses):

Instead of creating images or using flash just to show your site’s graphic text in the font you want, you can use typeface.js and write in plain HTML and CSS, just as if your visitors had the font installed locally. This is a work in progress, but functional enough at least to render the the graphic text on this site. Here’s what it takes to get going: load the typeface.js library and some typeface.js fonts, then proceed like normal:

  1. <script type="text/javascript" src="typeface-0.10.js"></script>
  2. <script type="text/javascript" src="helvetiker_regular.typeface.js"></script>
  4. <div class="myclass typeface-js" style="font-family: Helvetiker">
  5.     Text here in Helvetiker font...
  6. </div>

The examples area shows how the solution nicely integrates with CSS.

Having canvas and VML legacy support is great. It would be nice to allow the selection of text though, always a pain in the ….

Posted by Dion Almaer at 8:47 am

4 rating from 28 votes


Comments feed TrackBack URI

That’s just brilliant. Was about to implement sIFR on one project, but came here and I see this, perfect timing ;)

Comment by nea — October 27, 2008

Looking promising! If David wants to contact me at all to discuss mutual issues, problems run across, etc. I’d be more than happy to pool resources (see ).
Nice to see more people working the custom typography angle :)

Comment by ttrenka — October 27, 2008

not working in IE6, which means it’s basically useless in the real world. i hope i’m doing something wrong, cuz this got me excited.

Comment by ajaxery — October 27, 2008

This looks promising indeed. Do have a few questions about this though.
1)Do we really need this?
As Zuzana Licko once said:
In those cases you need to use something that is not necessarily intrinsically more legible, but that people are used to seeing. This is what makes certain typestyles more legible or comfortable. You read best what you read most. However, those preferences for typefaces such as Times Roman exist by habit, because those typefaces have been around longest. When those typefaces first came out, they were not what people were used to either. But because they got used, they have become extremely legible.

– Will people use the real bold, not some fake bold rendering?
– Will people make sure they have the right to embed the font?
– Do they know serif fonts are harder to read?

Comment by westworld — October 27, 2008

correction: VMWare Fusion does not show the text in IE6. But I was able to get on a PC, and it works!

Sorry about the confusion.

Comment by ajaxery — October 27, 2008

Aye, works on IE6 no problem, doesn’t work in Opera tho, but the sky won’t fall if one not-so-popular-after-all browser will have to render default font :p.

Comment by nea — October 27, 2008

Doesn’t work in Safari 2.0.4. If you can ignore that though…

Comment by bbobek — October 27, 2008

@westworld: Serif fonts are not harder to read, they’re easier to read; they’re just harder to correctly render at small sizes on a screen because the resolution is so low. That’s why hinting exists, and why fonts like Georgia and Cambria are so good.

Comment by eyelidlessness — October 27, 2008

If serif fonts were harder to head, novels wouldn’t use them.

Serif will come back into style when Sony and Amazon’s eInk books get high enough resolution to make them worthwhile.

Comment by Nosredna — October 27, 2008

Wow, very clean code to solve such a tricky issue:

I especially like the simple support for different back-ends.

Comment by K9 — October 27, 2008

I really appreciate his work, it’s an interesting hack, but that’s all.
I tested this first version, and it’s really really buggy …
Also it has the common accessibility problems as sIFR and is also slowing down the client, because everything is done front-end.

I’m just gonna wait for TTF support on the next versions of Firefox and Safari … and here we go a EOT file, a TTF … nothing more.

Comment by Yves — October 27, 2008

Regarding adding support for selectable text: one possible way to accomplish this is to overlay the fallback text some text over each canvas element, but give the text color of color: rgba(0, 0, 0, 0.0);

Then when they tried to select the rendered text, they would actually be selecting the hidden overlay text which would only show up when they try to select it.

If opacity:0.0 is set, then they can still select the text, but the text selection indicator doesn’t show up (at least in Firefox).

Comment by westonruter — October 27, 2008

I’m not sure I understand. If all that’s being done is “writ[ing] in plain HTML and CSS, just as if your visitors had the font installed locally”.

Isn’t this what pure CSS would do? Why not just create a CSS declaration applying a specific font to the selector and go from there? If the user doesn’t have the font, they won’t see the style.

If you’re not embedding the font, then why even bother?

Comment by commadelimited — October 27, 2008

This is awesome!

Comment by Brad Neuberg — October 27, 2008

@Yves: I don’t understand the accessibility problem. If the plain HTML is intact for screen readers, then where’s the accessibility issue? Bots will be able to see the text as well for indexing. I believe the problem comes when you don’t have a supported browser, which is less than a fraction of 1 percent of the internet. Please explain.

Also, is it really that slow to render? I haven’t really noticed.

Comment by ajaxery — October 27, 2008

I’ve done some samples. I successfully converted DejaVu fonts and used them. It is working very well for:
– Firefox 3
– IE6, IE7
– Chrome

But not in Opera. I didn’t see any signifant slowness for any browser.
I tried it with H1 tag but it didn’t work.

I definetely prefer it to sIFR.

Comment by sempsteen — October 27, 2008

@Brad Neuberg :
– the user can’t change the font-size by zooming on IE6 (at least 20% of the global market) and Safari (5% ?) > visual accessibility ;
– it’s not selectable > breaking common OS/browser features ;
– I’m not sure how the fallback is working on Jaws, WindowsEyes, Firevox, … I wanted to test it, but don’t had the time yet ;
– well you don’t realize it’s slowing down, but anyone using Win2k, Win98 or whatever might … so it’s just blotting the client for some customized font …

Whatever : great job, but not recommendable on important websites.

Comment by Yves — October 28, 2008

– For a majority of browsers, this solution _increases_ accessibility. The alternative (using images for fonts) also doesn’t work for zooming and is even more inaccessible.
– Not selectable: Neither are images
– About supporting Win2k, Win98: if we let that hold back the majority of the web, then everything fails. The installed base of thoses OSes is very small (even internationally in Internet Cafes, which tend to have older machines).

I believe this is closer to being used on major websites then Yves lets on, especially because it increases search engine friendliness (SEO), which is a big deal to companies, as well as potentially increasing accessibility.

Comment by Brad Neuberg — October 28, 2008

I’m generally suspicious of claims that text replacements hacks like CSS background-image replacement and sIFR are “accessible”, particularly when not backed up with evidence of testing across a broad range of usage scenarios.

For example, CSS background-image replacement that positions text off-screen fails to produce visible text for users who need to use their own (perhaps high contrast) color settings. sIFR typically positions the hidden “real” text exposed to assistive technology in a different place from the Flash movie replacement, which could (at least in theory) easily cause problems for users of screen magnifiers or text-to-speech aids that show a narrow view of focused text or select the text as they read it.

However, at least both off-screen text and sIFR-replaced text would work for users who are blind and using at least some popular screen reader/browser combinations. The replaced text in the official sIFR3 Beta 2 example is read out by all of the following screen reader/browser combinations with roughly default settings: JAWS 10 Beta with IE7 or Firefox 3; GW Micro Window-Eyes 7 with IE7 or Firefox 3; and Apple VoiceOver with WebKit Nightly. (Although JAWS 10 Beta appears to announce a Flash button for each replacement when used with Firefox.)

But if you try to read the offical Typeface.js example with the same user agents, you’ll find that the replaced text is not read by any of them.

I disagree with Brad Neuberg that the result with Typeface.js is more accessible than using IMG, in which case the ALT text will be read by screen readers and text-to-speech aids, all popular browsers provide functionality to access the alternative text (whether as a tooltip, or a properties dialogue, or by the option to turn images off), and screen magnifiers and browsers with zoom functionality (IE7, Opera, Firefox 3) can zoom the image along with the rest of the page (albeit suffering pixilation). Users are more likely to be able to work around established standards like IMG than new hacks.

Not that I’d advise using IMG either; plain text with CSS-applied fonts is infinitely preferable.

By the by, ajaxery’s comment above (“If the plain HTML is intact for screen readers”) appears to reflect a common misconception that a typical screen reader interacts with raw HTML much as Lynx interacts with it. In fact, popular screen readers provide a speech and braille interface for desktop environments and applications, using a range of APIs specific to those environments and applications, rather than interacting with HTML directly. They are thus highly dependent on how browsers and plugins represent web content to them via those APIs. (I’ve bookmarked some resources that serve as an introduction to how screen readers really work on Delicious, for those interested.) So in the case of Typeface.js, screen reader accessibility depends on how the VML and canvas objects that replace the HTML objects are represented to assistive technology over those APIs and on the assistive technology being programmed to handle the available information.

Comment by benjaminhawkeslewis — October 28, 2008

It’s not selectable (copy and paste doesn’t work) so it’s like using images for text. Not something that I’m going to use in one of my sites: it’s detrimental to the usefulness of their content so it will drive down traffic.

Comment by pmontrasio — October 28, 2008

Very cool, but the fact that it’s not actually selectable text is a buzz kill. Because of that I can’t envision using it for body text. Maybe headlines though… Definitely a good piece of code though!

Comment by mjuhl — November 18, 2008

That could prove useful

Comment by Remedies — November 19, 2008

Sometimes works on Safari/Chrome, and sometimes not.

Comment by drewlesueur — November 20, 2008

Orca Screen Reader + Firefox 3 on ubuntu 8.04 and 8.10 also does not read the example text on the typeface.js example (or any other canvas element that i have found which seems a bit crap)

Does jaws not give you a simple way to disable javascript? the page reads perfect if i do that.

Comment by eatmee — November 21, 2008

Solved the screen reader issue with a simple title attribute on the element (at least with Orca on ubuntu, tool tip shows up in ms ie7 so would assume JAWS works)

Doesn’t solve the _copy_ problem, but (in firefox {not ie7/safari} you can copy the text (from the title attribute) by right clicking on canvas and selecting “image properties”

Script is making elements vanish in konqueror :\

Comment by eatmee — November 22, 2008

Leave a comment

You must be logged in to post a comment.