如何以及何时使用sIFR

2022-07-15 80酷酷网 80kuku.com

　　作者：阿宏 2005-5-28 16:05:36

原文：
原作者：
翻译：

在分析sIFR之前，先来快速的了解一下sIFR是什么，以及它是如何工作的。sIFR表示scalable Inman Replacement，是一种在web上准确发布自定义排版的技术。这种技术的实现方法是，当页面下载时，在一个指定的元素中用渲染的文字来代替一些文本。理解下面这点是很重要的，这个元素并不是被完全替换，文本仍在元素内，这个元素仍可以像通常那样被样式化或者被定位。

关于sIFR的一些事实：并不是为了辩论

sIFR不需要更改(X)HTML代码，所有的工作由Javascript、和来完成；
如果用户没有安装或者不支持Javascript，那么(X)HTML的文本就会被样式化后显示出来。
sIFR是可缩放的，可以在渲染时更改为用户设置的缺省字体尺寸。
sIFR兼容所有的屏幕阅读机，至今还没有问题被报道出来。
sIFR的文本可以被鼠标选择，尽管当全选文本时，选中的状态看上去不那么确切。
sIFR不影响搜索引擎的定位和评定，不会隐藏真实的文本内容。

结论应该是，sIFR是一种可使用的，慎重的技术，设计者和开发者使用时应该给予认真的考虑。

什么时候使用sIFR

就像所有的web技术一样，重要的是要懂得使用sIFR的最好的方式，以及能够知道最适合使用的场合。这指的是要为工作选择恰当的工具，特别是当sIFR作为一个工具从工具箱中跳出让我们使用时。

案例：一个大型的体育新闻站点决定把所有的标题都设计成公司独有的字体。新闻报道（包括它们的标题）通过某些内容管理软件被世界各地不同的人在不同的地方发布。他们不可能雇佣一些人坐在Photoshop面前，当编辑们每次要增加新闻报道时就创建一张标题图片。

在这种情况下，sIFR就是一个绝对简单的，可使用的和可扩充的工具。一些新闻站点解决这个问题的办法是通过PHP来忙碌的创建图片，或者使用另一些服务器端的手段。这个办法可以很好的节省时间，但是当它与sIFR比较时，就会看到有许多缺点：

图片不能缩放为用户缺省的字体尺寸。
尽管图片被缓存在服务器上，但是在产生图片时仍然存在一个性能问题。
每一张图片都必须分别被下载，导致服务器和带宽的消耗。

而采用sIFR，那么就只有一个(.swf)文件和一个Javascript (.js)文件被下载，并可以使站点上所有的标题都被渲染为公司的字体。

这个例子不是空穴来风。这是一个真实的案例，在2001年，为了重新设计，开发出了最初的替换技术。从那以后，随着和其他人的加入，这已经发展成为今天我们所拥有的完整而流畅的技术了，而且很有可能在2005年对web排版技术产生重大的冲击。

在链接上使用sIFR

最新版本的sIFR允许链接文本被替换。尽管这是一个令人兴奋的发展，但毕竟不适合运用在这样的场合。这是由于以下的可访问性问题：

不支持浏览器的右键点击功能（上下文菜单）
不支持apple的option键
没有状态条信息

虽然这些问题显得很琐碎，但是很多人发现这些功能的缺失很令人丧气。缺少状态条的信息，你就不能获得你下一个要访问的地址的线索；随着诸如Firefox和Opera浏览器的普及，右键的上下文菜单正在变成一个越来越有用的工具。尽管sIFR在链接上提供一个基本的右键点击，但是浏览器的上下文菜单却是不可访问的。

当然，这是的限制而不是sIFR自身的限制。这些问题看上去可以在将来被克服。举个例子，状态条可以通过Javascript来控制，所以增加显示出链接目标的功能应该不是很困难。但是，在允许在链接上提供完整的浏览器上下文菜单之前，我相信sIFR还不能完全处理这类文本。

反锯齿

sIFR大多数的益处都集中在自定义字体的能力上，一个重要的考虑是文本可以被反锯齿。Web开发者经常会忘掉这一点，部分是因为如此多的工作是用Mac OS X完成的，它的Quartz字体可以产生平滑的边缘。然而，的使用者（尽管在显示菜单的某处有平滑字体边缘的选项）看起来并不能反锯齿，能够使这些用户，和预装 XP或Mac OS X的用户一样，拥有显示反锯齿标题的能力是一个重要的考虑因素。

精细调节

我听到有一个问题多次被提及，那就是sIFR不允许像控制一张图片所可能做的那样来控制文本。确实是这样。用Photoshop或者Fireworks创建的图片，你可以精确的控制字距，拉伸，反锯齿，或者另一些特性，诸如非常准确的下投影。图像编辑器是一个真正的WYSIWYG（所见即所得）的媒介。而渲染为的sIFR却不是。

如果需要达到这个层次的控制，那么一幅图片仍然是发布这类文本的最好的方法，在这些情况下sIFR不是正确的工具。但是，如果纯粹是要发布一个自定义的字体，那么sIFR就比创建图片更适合了。

下载速度

当使用sIFR时，替换文本的着色速度是一个重要的考虑因素，虽然从早期的版本以来，速度已经有了一个很大的提高，但是如果在同一时间屏幕上有很多的sIFR实例，那么还是有明显的延迟。（比如，每个页面有一个标题，或者每次传送都有标题）这个例子也许可以最好的说明，为什么适度的使用sIFR是当前使用这项技术的理想方式。

这是使用替换技术的最令人丧气的缺点了。从实现第一个sIFR时起，这诱惑便是在一个页面上替换太多的元素。为了实现它们，下载的速度必须有非常大的提高；虽然一个好的服务器可以帮助你，但是真正消耗时间的是运行那些体积庞大的Javascript。