Introducing sIFR: The Healthy Alternative to Browser Text » Mike Industries (original) (raw)

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

It’s been well over ten years now since the debut of the graphical web browser and we still don’t have an easy way to deliver rich typography using HTML/CSS. With CSS we can size, style, color, kern, show, and hide our text but we can’t deliver something classical typesetters have delivered since at least the 15th century: custom typography. Until now. In concert with Shaun Inman and Tomas Jogin, I am releasing into the public domain a scalable, multiline, Flash 6 compatible version of IFR to help you reduce the amount of browser text in your life and free the world from the scourge of Arial.

An updated example of sIFR (now at version 2.0) is available here.

But first, a little history

Custom typography for the masses made its debut on computers in 1984 with the release of the Apple Macintosh. The original Mac came pre-installed with such jewels as Chicago, Geneva, New York, and London. As more foundries released digital Postscript versions of their masterpieces over the next several years, the pool of available typefaces grew to thousands. Want to design a wedding invitation? Use Sloop. Want to emulate an artist’s handwriting? Use Cezanne. Want to throw together a cheesy HR flyer? Use Comic Sans. The possibilities are endless, and in some cases, scary.

Then along came the web.

Originally used to spread technical documents across networks, the early web had no need for anything but the barest of typographic essentials. There was no imagery, no sound, no animation, no color, and none of the niceties we are used to seeing on the 21st century web. With the introduction of the Mosaic graphical web browser in 1993, this began to change. Text could now be rendered using any font installed on a user’s system.

A technology before its time?

This newfound support for custom typefaces was nice, but it ended up being of limited use for the following two reasons:

  1. Postscript typefaces were not represented on screen by their beautiful font outlines but rather by jaggy (“aliased”) bitmaps specially designed for low resolution displays. What this meant was that unless typeface designers created special bitmaps for each possible size on screen, the font ended up looking like crap. Even today, the best web typefaces (viz. Verdana, Tahoma, Helvetica) have been specially adapted for low-resolution displays and that’s why they look so clean on screen.
  2. There is only a tiny subset of fonts commonly installed on Macs, PCs, and (some) Linux machines. These include the usual suspects: Verdana, Times, Georgia, Helvetica, Courier, and the ugly kid in the corner that no one likes — Arial. Since most people have nothing but these core fonts installed on their systems, it is futile for a designer to specify another font to use on their web site when the user is unable to display it.

Eleven years later, the situation is finally changing. Mac OS X uses Quartz technology to display true Postscript anti-aliased fonts on-screen and the effect is stunning. Windows uses a slightly inferior technology called ClearType to accomplish a slightly inferior version of the same thing. With this newfound ability to display true versions of typefaces in web browsers, you’d think typography on the web would be exploding. Well it’s not. Why? Because no one has solved the second problem yet: how to deliver custom typefaces to people who don’t have them installed.

Premature proprietary panaceas

Several years ago, three possible solutions to this problem were floated out to the web development community. Netscape introduced a feature called “Dynamic Fonts” which downloaded a temporary character set for whatever font the designer had specified. This solution only worked in Netscape browsers of course. Then Bitstream, a renown type foundry, released a plug-in called the “Bitstream Font Player” which purported to do the same thing via a more compatible plug-in model. Eventually, Internet Explorer broke this functionality and Microsoft introduced their own solution for dynamic fonts: the very creatively named Web Embedding Fonts Tool, or WEFT. WEFT fonts took the form of downloadable EOT files which actually worked pretty well in PC Internet Explorer but were totally unsupported in any other browser or OS.

The problem with all of these solutions was that they were not compatible across OSes and browsers, but perhaps more importantly, they were too far ahead of their time. Who wants to view a custom font if it can’t be rendered as its designer intended, with anti-aliased Postscript goodness?

So here we are in 2004 and no one has come up with an easy solution to the problem of custom typography on the web.

Flash to the rescue

With today’s release of sIFR, or Scalable Inman Flash Replacement, we finally have a standards-compliant way to deliver rich typographical text in a flexible manner to over 90% of web users. What is this all about, you ask? Here’s a brief overview of how we got here:

In 2001, I redesigned ESPN.com employing a custom-built Flash 4 component to display our headlines in bold anti-aliased Akzidenz Grotesk (the official ESPN on-air typeface). Using inline javascript, we were able to display rich headlines to people who had Flash 4 installed and plain text to those who didn’t. Additionally, the Flash component automatically scaled down all headlines to fit on one line no matter how much text was entered. The rich headlines drew praise from our users and the negative effect on the code was minimal.

Two years later, Shaun Inman invented a much better technique of embedding Flash headlines by not embedding them at all. Instead, Shaun wrote his pages out as standard XHTML and then used javascript and the Document Object Model to replace all designated text with Flash-rendered text a split second after the page had loaded. Known as IFR, or Inman Flash Replacement, this method was rightly praised by the web community for enabling rich typography without affecting any underlying XHTML code. The method had many revolutionary features and only a few shortcomings, the most glaring of which was the lack of support for multiple lines of text.

Several months after Shaun released IFR into the wild, Tom Werner and Rob Cameron built on Shaun’s code and released their own version called WAC-FR, or Werner and Cameron Flash Replacement. Tom and Rob proved that there was a lot more work to be done in the world of Flash Replacement by introducing a great set of features including support for multiple lines, CSS, and scalability based on a user’s text-zoom setting. The main drawbacks of WAC-FR were that it required Flash 7, it relied on a character count to estimate how many characters might fit on a line, and it sometimes used multiple Flash movies for single blocks of text. As of the summer of 2004, Flash 7 penetration is at about 60% so WAC-FR probably can’t be considered a solution for the masses yet, but that percentage improves every day.

As part of a major yet-to-be announced redesign project (think ESPN big… details soon), I had to come up with a way to display multiple line Flash headlines while keeping compatibility with Flash 6. Furthermore, the headlines had to adapt automatically to areas of different heights and widths.

sIFR is born

sIFR approaches text replacement in a totally different way than previous methods:

The following explains the sIFR process:

  1. A page is requested and loaded.
  2. Javascript detects if Flash 6 or greater is installed.
  3. If no Flash is detected, the page is drawn as normal.
  4. If Flash is detected, the HTML element of the page is immediately given the class “hasFlash”. This effectively hides all text areas to be replaced but keeps their bounds intact. The text is hidden because of a style in the stylesheet which only applies to elements that are children of the html.hasFlash element.
  5. The javascript traverses through the DOM and finds all elements to be replaced. Once found, the script measures the offsetWidth and offsetHeight of the element and replaces it with a Flash movie of the same dimensions.
  6. The Flash movie, knowing its textual content, creates a dynamic text field and renders the text at a very large size (96pt).
  7. The Flash movie reduces the point size of the text until it all fits within the overall size of the movie.

This, of course, all happens too quickly for the user to even notice what’s going on, but below is a super slow motion example of the process (Flash required to see demo):

In addition to the improvements I’ve made to the original IFR on the Flash side of things, I worked with the incomparable Tomas Jogin to improve the replacement script itself. Tomas wrote in an entry several weeks ago that he wanted IFR to be able to replace not only structural elements like H1s and H2s, but all HTML elements, including DIVs. Tomas rewrote a portion of Shaun’s original IFR script to accomplish just that. So now we have in sIFR a solution which can dynamically replace any element of any height or width with a Flash movie that will correctly display one or multiple lines of text.

As another added bonus, I’ve built in the ability to automatically keep the Flash text linkable if the normal HTML version was linkable. You can even configure it so underlines show up when you hover over the text.

But will it scale?

With sIFR comes the introduction of a new feature I call “lazy scaling”. Since sIFR lets the original browser text determine the height and width of the area to be replaced, that area scales with the user’s text zoom setting. While WAC-FR does a great job of scaling on-the-fly when a user resizes text, sIFR only scales on page load. This is not much of a sacrifice in my opinion because firstly, I expect users to use sIFR mainly for text that is already large enough to see clearly, and secondly, because if a user is vision-impaired, they are probably surfing the web with text zoom consistently on. I don’t expect a lot of people are toggling between text zoom settings dynamically for every page they visit.

Limitations

The only significant restriction I am aware of so far is that you shouldn’t use Flash text which is markedly narrower than your browser text. Using text that is wider is no problem since Flash will just shrink it to fit, but for best results, try to match the metrics of your Flash font as closely as possible to the metrics of your browser font. Don’t be afraid to use negative kerning on your browser text if you have to. What I did was render a couple of lines of the custom font in Photoshop, take a screenshot, pull it into Dreamweaver, and overlay browser text on top of it. This way, you can tweak the kerning, leading, size, and weight of your browser text until you get a close match. You don’t have to get it perfect… just get it so that the browser text takes up either the same space or slightly less space than the custom font text. This is a one-time process and it only takes a few minutes.

If you must use markedly narrower Flash text, you can hack the script so that as soon as Flash is detected, your browser text is given extreme negative kerning values before the headline boxes are measured.

How to use it

Grafting sIFR into your site is simple:

  1. Open up “sIFR.fla”, double-click the font item in the library, and choose any font installed on your system. Export the movie out as “sIFR.swf” or whatever name you’d like.
  2. Set the CSS properties of your browser text as mentioned in the paragraph above.
  3. Set which items you’d like to replace at the bottom of the “sIFR.js” file.
  4. Include the “sIFR.js” file in the head element of your pages.

That’s it! You’ve just freed yourself from the typographical constraints of browser text.

What’s next for web typography?

While sIFR is a liberating solution, it clearly falls into the category of “things which shouldn’t have to be done”. Not coincidentally, this is the same category a lot of things on the web fall into. Using floats to create column layouts, using javascript to clear absolutely positioned elements, using empty alt tags, using image replacement methods, etc, etc, etc. There are simply a lot of things we do as web developers because of the glacial pace at which standards manifest themselves. Do we like standards? Yes, we do. But will we sacrifice our own ability to create better work on the web because of them? No, we won’t. Well, some people will.

I won’t.

In working through sIFR, I began to think of ways browser manufacturers could quickly implement anti-aliased custom typography. The only possible answer I could think of was licensing Flash’s rendering engine. We’ve already proven that Flash can render text as we like on all platforms, and we’ve already seen that every new version of Flash penetrates over 85% of computers within 14 months, so why can’t there be some sort of standard declaration in browsers which invokes a Flash font outline file and renders designated text in that typeface? Ideally, it would be a CSS declaration like so:

h1 {font-family-enhanced: "futura.swf"}

Update: It has been brought to my attention that the @font-face declaration is already part of the CSS2 spec (I thought it was just a Microsoft addition), so perhaps something like this instead:

@font-face {font-family: "Futura"; src: url("futura.swf") format("opentype", "flash");}

Since it’s a new property, it wouldn’t break any existing sites and would degrade gracefully as well. I know this sort of solution might be sacrilegious to the W3C, but what about the more progressive, quicker moving, less idealistic WHATWG? Here’s a group that is interested in improving browsers NOW, damn the purists. I really love what the WHATWG is doing in the HTML space these days, but I wonder if typography is even on their plate. Hey Macromedia, how about organizing a kegger with those guys or something?

In conclusion

Please feel free to use sIFR in your own projects or wherever the situation calls for it. I am under no illusions that this solution is perfect yet, so if you notice quirks or have improvements to suggest, please post them here. I will be happy to roll any improvements into new builds as soon as they are judged as such.

sIFR is offered free of charge, but also free of customer service. I usually try to answer all questions readers submit, but my time is limited.

Right-click here to download the latest sIFR (1.1.4) or check out an example online.

sIFR is now at version 2.0. Please see the most recent sIFR article for details, files, and examples.

Alright, have at it!