sIFR 2.0: Rich Accessible Typography for the Masses

据网上资料，对汉字还有点无能为力                                     

comes from: http://www.mikeindustries.com/blog/sifr/

 

Over the last several months, a small group of web developers and designers have been hard at work perfecting a method to insert rich typography into web pages without sacrificing accessibility, search engine friendliness, or markup semantics. The method, dubbed sIFR (or Scalable Inman Flash Replacement), is the result of many hundreds of hours of designing, scripting, testing, and debugging by Mike Davidson (umm, that’s me) and Mark Wubben. Through this extensive work, we, along with a invaluable stable of beta testers, supporters, and educators like Stephanie Sullivan and Danilo Celic of Community MX, have completely rebuilt a DOM replacement method originally conceived by Shaun Inman into a typography solution for the masses. It is this technology which provides the nice looking custom type headlines you see on sites like this one, Nike, ABCNews, Aston Martin, and others. We’ve released sIFR to the world as open source, under the CC-GNU LGPL license, so anyone can use it free of charge.

Anyone who has been following the developments with sIFR over the last several months is already aware of most of the information on this page, but this being the newly official sIFR 2.0 landing page, an overview of the technology is below. Also, feel free to read the complete historical perspective in my original post Introducing sIFR: The Healthy Alternative to Browser Text.

How it works

sIFR is meant to replace short passages of plain browser text with text rendered in your typeface of choice, regardless of whether or not your users have that font installed on their systems. It accomplishes this by using a combination of javascript, CSS, and Flash. Here is the entire process:

1. A normal (X)HTML page is loaded into the browser.
2. A javascript function is run which first checks that Flash is installed and then looks for whatever tags, ids, or classes you designate.
3. If Flash isn’t installed (or obviously if javascript is turned off), the (X)HTML page displays as normal and nothing further occurs. If Flash is installed, javascript traverses through the source of your page measuring each element you’ve designated as something you’d like “sIFRed”.
4. Once measured, the script creates Flash movies of the same dimensions and overlays them on top of the original elements, pumping the original browser text in as a Flash variable.
5. Actionscript inside of each Flash file then draws that text in your chosen typeface at a 6 point size and scales it up until it fits snugly inside the Flash movie.

This all happens in a split-second, so all of the checking, replacing, and scaling is not visible to the user. It is not uncommon to notice a very short delay as the Flash loads, but to the user, none of the internals of this process are exposed.

From a technical standpoint, a lot more stuff is happening, but that is a top-level overview. The only other material part of the process that is important from a developer/designer perspective is how CSS styles change during all of this. Your (X)HTML document starts off with its standard styles. Then, once sIFR determines it will run, your html and body tags are classed with “.sIFR-hasFlash”. This is done in order to accomplish two things: 1) to hide your browser text as the method is running, and 2) to create “decoy” styles for the text you are replacing. Decoy styles are never seen by the user. They are meant to adjust the space the browser text takes up before the measurement and replacement occurs. This is necessary because your browser text might be a narrow font and your Flash text might be a wide font. So in other words, something that takes up one line in browser text might take up three lines in Flash text. In the above case, you’d set your decoy style on the browser text to something like “letter-spacing: 10px;” to widen it to match the Flash text. This process is called “font tuning” and it’s really the only potentially tricky part of sIFR. Everything else is cake. Because you can’t explicitly set the size of your fonts in sIFR, your sIFR fonts will take their cues from your browser fonts. Match them up by adjusting your decoy styles and sizing will take care of itself (more details on how to do this are in the documentation).

Accessibility details

sIFR is fully accessible to screenreaders and other assistive technology. Don’t take our word for it. Ask Matt May of the W3C who endorses it as an accessible method to create rich typography on the web. Or ask Joe Clark, one of the world’s leading accessibility experts, whose interest in typography is only trumped by his interest in accessibility.

The knee-jerk reaction of some people whenever they see Flash is that it must be inaccessible because it’s Flash. What we’ve done with sIFR, however, is turn that model completely on its head. Your (X)HTML document is still the exact same document it was before sIFR kicked in. Your code is untouched and sIFR is completely abstracted to the javascript layer; therefore, your accessibility, your search engine friendliness, and your semantics are the same as they were before the day you decided you like nice fonts.

In addition to the obvious accessibility features, sIFR text can also be selected, copied, and pasted by users. It also zooms with the user’s text-zoom settings, although this only occurs on page load and not on-the-fly. And finally, of course sIFR works with linked text (anchors).

Compatibility

sIFR works on Mac, Windows, and Linux machines with javascript turned on and Flash 6 or greater. As far as browser support goes, it’s great on all the majors and even some of the minors: PC IE 5+, Safari, Firefox, Opera 7+, Omniweb, and even Konqueror. We estimate this covers over 90% of consumer-grade machines in the world.

The beautiful part, however, is that if any of the above conditions aren’t met, users will see the exact same content, only without the sIFR text. Standard browser text will appear instead.

Permanence

sIFR snaps right in and lifts right out. This is an important point. Making the decision to use sIFR is often just a question of adding a .js include to your site, uploading a .swf and some .css files to your server, tuning your fonts, and that’s it. It generally doesn’t require any wholesale code or design changes, and should you decide at some point in the future that you don’t want to use it, simply remove the .js file and you’re back to browser text.

While sIFR gives us better typography today, it is clearly not the solution for the next 20 years. It is but a nice stopgap for people who value the importance of typography and don’t want to wait 1, 5, or 10 years for browser makers, OS vendors, and type foundries to figure out a better solution. The moment that happens however, sIFR will lift right out and give way to whatever other method is available.

Bandwidth

The sIFR javascript file is less than 10k and only loads once. Thereafter, it is pulled from the browser cache. The same applies to the sIFR Flash movies which contain your fonts. If you have five headlines on a page which all use the same custom font, the .swf is pulled once from the server and from the browser cache thereafter. sIFR Flash movies are generally between 8k and 20k depending on the complexity of the font.

Flash/ad blockers

We’ve worked with the developers of the Firefox FlashBlock extension to make sure sIFR text is automatically degraded to (X)HTML for users of recent versions of FlashBlock. When users install FlashBlock, they are demonstrating a bias against Flash (most likely because of the incredible amount of obnoxious and invasive advertising on the web these days) and we want to respect this bias. If users don’t want to see Flash, we don’t want to show it to them. sIFR runs fine under other extensions like AdBlock, but users can always disable the loading of sifr.js if they’d like.

Proper use and best practices

sIFR is a powerful tool. So powerful, in fact, that you can completely ruin a web page with it if you get overzealous and don’t exercise restraint. Early on in development, a dude in Texas e-mailed me and asked me why his sIFR-ized page took 30 seconds to load. I looked at the page and he had replaced every single word with sIFR text… even complete paragraphs and 300-word passages. Do not do this please! sIFR is for headlines, pull quotes, and other small swaths of text. In other words, it is for display type — type which accents the rest of the page. Body copy should remain browser text. Additionally, we recommend not replacing over about 10 blocks of text per page. A few more is fine, but once you get into the 50s or so, you’ll notice a processor and speed hit.

There also are two features we put into sIFR by user request which can be used, but developers and designers should know the downsides. One is the ability to use transparent backgrounds in the Flash movies so that your page background shows through. This is supported in PC IE, PC Opera 8, newer versions of Safari and Firefox, and a few other browsers, but not every single one. The result is that browsers which don’t support transparency will render Flash movies with a background color that you specify as your “fallback” color. Furthermore, transparent Flash movies take up a bit more CPU power than non-transparent ones. The second thing is using sIFR for linked text. While this works just fine, please be aware that users will lose the ability to right-click or middle-click these links and have them open in a new window. This may or may not be important to you.