如何以及何时使用sIFR

在分析sIFR之前，先来快速的了解一下sIFR是什么，以及它是如何工作的。sIFR表示scalableInmanFlashReplacement，是一种在web上准确发布自定义排版的技术。这种技术的实现方法是，当页面下载时，在一个指定的元素中用Flash渲染的文字来代替一些文本。理解下面这点是很重要的，这个元素并不是被Flash完全替换，文本仍在元素内，这个元素仍可以像通常那样被样式化或者被定位。关于sIFR的一些事实：并不是为了辩论sIFR不需要更改(X)HTML代码，所有的工作由javascript、Flash和CSS来完成；如果用户没有安装Flash或者不支持javascript，那么(X)HTML的文本就会被CSS样式化后显示出来。sIFR是可缩放的，可以在渲染时更改为用户设置的缺省字体尺寸。sIFR兼容所有的屏幕阅读机，至今还没有问题被报道出来。sIFR的文本可以被鼠标选择，尽管当全选文本时，选中的状态看上去不那么确切。sIFR不影响搜索引擎的定位和评定，不会隐藏真实的文本内容。结论应该是，sIFR是一种可使用的，慎重的技术，设计者和开发者使用时应该给予认真的考虑。什么时候使用sIFR就像所有的web技术一样，重要的是要懂得使用sIFR的最好的方式，以及能够知道最适合使用的场合。这指的是要为工作选择恰当的工具，特别是当sIFR作为一个工具从工具箱中跳出让我们使用时。案例：一个大型的体育新闻站点决定把所有的独有的字体。新闻报道（包括它们的标题）通过某些内容管理软件被世界各地不同的人在不同的地方发布。他们不可能雇佣一些人坐在Photoshop面前，当编辑们每次要增加新闻报道时就创建一张标题图片。在这种情况下，sIFR就是一个绝对简单的，可使用的和可扩充的工具。一些新闻站点解决这个问题的办法是通过PHP来忙碌的创建图片，或者使用另一些服务器端的手段。这个办法可以很好的节省时间，但是当它与sIFR比较时，就会看到有许多缺点：图片不能缩放为用户缺省的字体尺寸。尽管图片被缓存在服务器上，但是在产生图片时仍然存在一个性能问题。每一张图片都必须分别被下载，导致服务器和带宽的消耗。而采用sIFR，那么就只有一个Flash(.swf)文件和一个javascript(.js)文件被下载，并可以使站点上所有的标的字体。这个例子不是空穴来风。这是一个真实的案例，在2001年，为了重新设计ESPN.com，MikeDavidson开发出了最初的Flash替换技术。从那以后，随着ShaunInman和其他人的加入，这已经发展成为今天我们所拥有的完整而流畅的技术了，而且很有可能在2005年对web排版技术产生重大的冲击。在链接上使用sIFR最新版本的sIFR允许链接文本被替换。尽管这是一个令人兴奋的发展，但毕竟不适合运用在这样的场合。这是由于以下的可访问性问题：不支持浏览器的右键点击功能（上下文菜单）不支持apple的option键没有状态条信息虽然这些问题显得很琐碎，但是很多人发现这些功能的缺失很令人丧气。缺少状态条的信息，你就不能获得你下一个要访问的地址的线索；随着诸如Firefox和Opera浏览器的普及，右键的上下文菜单正在变成一个越来越有用的工具。尽管sIFR在链接上提供一个基本的右键点击，但是浏览器的上下文菜单却是不可访问的。当然，这是Flash的限制而不是sIFR自身的限制。这些问题看上去可以在将来被克服。举个例子，状态条可以通过javascript来控制，所以增加显示出链接目标的功能应该不是很困难。但是，在Flash允许在链接上提供完整的浏览器上下文菜单之前，我相信sIFR还不能完全处理这类文本。反锯齿sIFR大多数的益处都集中在自定义字体的能力上，一个重要的考虑是Flash文本可以被反锯齿。Web开发者经常会忘掉这一点，部分是因为如此多的工作是用MacOSX完成的，它的Quartz字体可以产生平滑的边缘。然而，Windows的使用者（尽管在显示菜单的某处有平滑字体边缘的选项）看起来并不能反锯齿，能够使这些用户，和预装WindowsXP或MacOSX的用户一样，拥有显示反锯齿标题的能力是一个重要的考虑因素。精细调节我听到有一个问题多次被提及，那就是sIFR不允许像控制一张图片所可能做的那样来控制文本。确实是这样。用Photoshop或者Fireworks创建的图片，你可以精确的控制字距，拉伸，反锯齿，或者另一些特性，诸如非常准确的下投影。图像编辑器是一个真正的WYSIWYG（所见即所得）的媒介。而渲染为Flash的sIFR却不是。如果需要达到这个层次的控制，那么一幅图片仍然是发布这类文本的最好的方法，在这些情况下sIFR不是正确的工具。但是，如果纯粹是要发布一个自定义的字体，那么sIFR就比创建图片更适合了。下载速度当使用sIFR时，替换文本的着色速度是一个重要的考虑因素，虽然从早期的版本以来，速度已经有了一个很大的提高，但是如果在同一时间屏幕上有很多的sIFR实例，那么还是有明显的延迟。（比如，每个页面有一个标题，或者每次传送都有标题）这个例子也许可以最好的说明，为什么适度的使用sIFR是当前使用这项技术的理想方式。这是使用Flash替换技术的最令人丧气的缺点了。从实现第一个sIFR时起，这诱惑便是在一个页面上替换太多的元素。为了实现它们，下载的速度必须有非常大的提高；虽然一个好的服务器可以帮助你，但是真正消耗时间的是运行那些体积庞大的javascript。总结sIFR并不会和图片替换技术相竞争；它是针对不同工作的独特的工具。它能被最好的使用在那些显示为浏览器缺省字体大小的，而又不能替换为自建图片的文本上。sIFR理想的使用场合是，当你想要仅用一张图片就显示自定义的字体或者反锯齿的标题时。这在web上被非常频繁的使用，在这些案例中sIFR是一个更好的选择。它可以缩放为用户缺省的字体尺寸，可以被选择，可以使用在数以千计的页面上而只需要下载一两个文件。摘要在页面标题上使用sIFR。有限度的使用sIFR，以获得最佳的下载时间。不要在链接上使用sIFR。