• 原文：http://usabletype.com/articles/2004/how-and-when-to-use-sifr/
• 原作者：Andrew Hume
• 翻譯：阿宏

在分析sIFR之前，先來快速的了解一下sIFR是什么，以及它是如何工作的。sIFR表示scalable Inman Flash Replacement，是一種在web上準確發布自定義排版的技術。這種技術的實現方法是，當頁面下載時，在一個指定的元素中用Flash渲染的文字來代替一些文本。理解下面這點是很重要的，這個元素并不是被Flash完全替換，文本仍在元素內，這個元素仍可以像通常那樣被樣式化或者被定位。

• sIFR不需要更改(X)HTML代碼，所有的工作由Javascript、Flash和CSS來完成；
• 如果用戶沒有安裝Flash或者不支持Javascript，那么(X)HTML的文本就會被CSS樣式化后顯示出來。
• sIFR是可縮放的，可以在渲染時更改為用戶設置的缺省字體尺寸。
• sIFR兼容所有的屏幕閱讀機，至今還沒有問題被報道出來。
• sIFR的文本可以被鼠標選擇，盡管當全選文本時，選中的狀態看上去不那么確切。
• sIFR不影響搜索引擎的定位和評定，不會隱藏真實的文本內容。

結論應該是，sIFR是一種可使用的，慎重的技術，設計者和開發者使用時應該給予認真的考慮。

就像所有的web技術一樣，重要的是要懂得使用sIFR的最好的方式，以及能夠知道最適合使用的場合。這指的是要為工作選擇恰當的工具，特別是當sIFR作為一個工具從工具箱中跳出讓我們使用時。

案例：一個大型的體育新聞站點決定把所有的標題都設計成公司獨有的字體。新聞報道（包括它們的標題）通過某些內容管理軟件被世界各地不同的人在不同的地方發布。他們不可能雇傭一些人坐在Photoshop面前，當編輯們每次要增加新聞報道時就創建一張標題圖片。

在這種情況下，sIFR就是一個絕對簡單的，可使用的和可擴充的工具。一些新聞站點解決這個問題的辦法是通過PHP來忙碌的創建圖片，或者使用另一些服務器端的手段。這個辦法可以很好的節省時間，但是當它與sIFR比較時，就會看到有許多缺點：

• 圖片不能縮放為用戶缺省的字體尺寸。
• 盡管圖片被緩存在服務器上，但是在產生圖片時仍然存在一個性能問題。
• 每一張圖片都必須分別被下載，導致服務器和帶寬的消耗。

而采用sIFR，那么就只有一個Flash(.swf)文件和一個Javascript (.js)文件被下載，并可以使站點上所有的標題都被渲染為公司的字體。

這個例子不是空穴來風。這是一個真實的案例，在2001年，為了重新設計ESPN.com，Mike Davidson開發出了最初的Flash替換技術。從那以后，隨著Shaun Inman和其他人的加入，這已經發展成為今天我們所擁有的完整而流暢的技術了，而且很有可能在2005年對web排版技術產生重大的沖擊。

最新版本的sIFR允許鏈接文本被替換。盡管這是一個令人興奮的發展，但畢竟不適合運用在這樣的場合。這是由于以下的可訪問性問題：

• 不支持瀏覽器的右鍵點擊功能（上下文菜單）
• 不支持apple的option鍵
• 沒有狀態條信息

雖然這些問題顯得很瑣碎，但是很多人發現這些功能的缺失很令人喪氣。缺少狀態條的信息，你就不能獲得你下一個要訪問的地址的線索；隨著諸如Firefox和Opera瀏覽器的普及，右鍵的上下文菜單正在變成一個越來越有用的工具。盡管sIFR在鏈接上提供一個基本的右鍵點擊，但是瀏覽器的上下文菜單卻是不可訪問的。

當然，這是Flash的限制而不是sIFR自身的限制。這些問題看上去可以在將來被克服。舉個例子，狀態條可以通過Javascript來控制，所以增加顯示出鏈接目標的功能應該不是很困難。但是，在Flash允許在鏈接上提供完整的瀏覽器上下文菜單之前，我相信sIFR還不能完全處理這類文本。

sIFR大多數的益處都集中在自定義字體的能力上，一個重要的考慮是Flash文本可以被反鋸齒。Web開發者經常會忘掉這一點，部分是因為如此多的工作是用Mac OS X完成的，它的Quartz字體可以產生平滑的邊緣。然而，Windows的使用者（盡管在顯示菜單的某處有平滑字體邊緣的選項）看起來并不能反鋸齒，能夠使這些用戶，和預裝Windows XP或Mac OS X的用戶一樣，擁有顯示反鋸齒標題的能力是一個重要的考慮因素。

我聽到有一個問題多次被提及，那就是sIFR不允許像控制一張圖片所可能做的那樣來控制文本。確實是這樣。用Photoshop或者Fireworks創建的圖片，你可以精確的控制字距，拉伸，反鋸齒，或者另一些特性，諸如非常準確的下投影。圖像編輯器是一個真正的WYSIWYG（所見即所得）的媒介。而渲染為Flash的sIFR卻不是。

如果需要達到這個層次的控制，那么一幅圖片仍然是發布這類文本的最好的方法，在這些情況下sIFR不是正確的工具。但是，如果純粹是要發布一個自定義的字體，那么sIFR就比創建圖片更適合了。

當使用sIFR時，替換文本的著色速度是一個重要的考慮因素，雖然從早期的版本以來，速度已經有了一個很大的提高，但是如果在同一時間屏幕上有很多的sIFR實例，那么還是有明顯的延遲。（比如，每個頁面有一個標題，或者每次傳送都有標題）這個例子也許可以最好的說明，為什么適度的使用sIFR是當前使用這項技術的理想方式。

這是使用Flash替換技術的最令人喪氣的缺點了。從實現第一個sIFR時起，這誘惑便是在一個頁面上替換太多的元素。為了實現它們，下載的速度必須有非常大的提高；雖然一個好的服務器可以幫助你，但是真正消耗時間的是運行那些體積龐大的Javascript。

sIFR并不會和圖片替換技術相競爭；它是針對不同工作的獨特的工具。它能被最好的使用在那些顯示為瀏覽器缺省字體大小的，而又不能替換為自建圖片的文本上。

sIFR理想的使用場合是，當你想要僅用一張圖片就顯示自定義的字體或者反鋸齒的標題時。這在web上被非常頻繁的使用，在這些案例中sIFR是一個更好的選擇。它可以縮放為用戶缺省的字體尺寸，可以被選擇，可以使用在數以千計的頁面上而只需要下載一兩個文件。

• 在頁面標題上使用sIFR。
• 有限度的使用sIFR，以獲得最佳的下載時間。
• 不要在鏈接上使用sIFR。

• Mike Davidson: Introducing sIFR: The Healthy Alternative to Browser Text
• Mike Davidson: sIFR 2.0 RC 3 is Here... Come Get Some
• Dave Shea on sIFR