sIFR 还是 FLIR？
我最近接触到了整容术，这是 sIFR 的替代方案，我想知道那些同时拥有 sIFR 和 FLIR 经验的人是否可以介绍一下他们使用 FLIR 的经验。
对于那些还没有了解 FLIR 工作原理的人来说，FLIR 的工作原理是使用 JavaScript 从目标元素中获取文本，然后调用 PHP 应用程序，该应用程序使用 PHP 的 GD 来渲染并返回透明 PNG 图像，这些图像被放置为所述元素的背景，然后将溢出设置为隐藏，并应用等于元素尺寸的填充，以有效地将文本推出视图之外。
这是我到目前为止所想到的：
好处
- 无闪光灯（+适用于手机）
- FLIR 不会破坏布局
- 图片大小从 1KB（例如一个 h3 句子）到 8KB（非常非常大的标题）不等
- 良好的文档
- 易于实施
- 可自定义选择器
- 支持 jQuery/prototype/scriptaculous/mooTools
- FLIR 已实现缓存
- 浏览器会自行缓存图像！
坏处
- 无法选择文本
- 处理来自所有来源的请求（您需要自行限制 FLIR 仅处理来自您的域的请求）
我主要关心的是它的扩展性如何，即成本有多高它可以在共享主机上与 GD 库一起使用，有人有这方面的经验吗？ 其次，知道 a) 文本没有显式隐藏 b) 仅在 JavaScript 引擎上呈现，搜索引擎对 sIFR 或 FLIR 实现有何喜爱。
I've recently bumped into facelift, an alternative to sIFR and I was wondering if those who have experience with both sIFR and FLIR could shed some light on their experience with FLIR.
For those of you who've not yet read about how FLIR does it, FLIR works by taking the text from targeted elements using JavaScript to then make calls to a PHP app that uses PHP's GD to render and return transparent PNG images that get placed as background for the said element, where the overflow is then set to hidden and padding is applied equal to the elements dimensions to effectively push the text out of view.
This is what I've figured so far:
The good
- No flash (+for mobiles)
- FLIR won't break the layout
- Images range from some 1KB (say one h3 sentence) to 8KB (very very large headline)
- Good documentation
- Easy to implement
- Customizable selectors
- Support for jQuery/prototype/scriptaculous/mooTools
- FLIR has implemented cache
- Browsers cache the images themselves!
The bad
- Text can't be selected
- Requests are processed from all sources (you need to restrict FLIR yourself to process requests from your domain only)
My main concerns are about how well does it scale, that is, how expensive is it to work with the GD library on a shared host, does anyone have experience with it?; second, what love do search engines garner for sIFR or FLIR implementations knowing that a) text isn't explicitly hidden b) renders only on a JavaScript engine.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
从长远来看，sIFR 应该能够更好地缓存，因为渲染是在客户端从单个 Flash 影片完成的。 Flash 文本的行为更像是浏览器文本而不是图像，并且可以轻松地在 Flash 中设置文本样式（不同的颜色、字体粗细、链接等）。 您可能还更喜欢 Flash 中呈现的文本质量，而不是服务器端图像库呈现的文本质量。 另一个优点是您不需要任何服务器端代码。
Google 表示 sIFR 是可以的，因为它用相同的文本替换 HTML 文本，但呈现方式不同。 我想说 FLIR 也是如此。
Over the long term, sIFR should cache better because rendering is done on the client side, from one single Flash movie. Flash text acts more like browser text than an image, and it's easy to style the text within Flash (different colors, font weights, links, etc). You may also prefer the quality of text rendered in Flash, versus that rendered by the server side image library. Another advantage is that you don't need any server side code.
Google has stated that sIFR is OK, since it's replacing HTML text by the same text, but rendered differently. I'd say the same holds true for FLIR.
我知道使用 sIFR，并且我假设使用 FLIR，您会以与平常相同的方式执行标记，但使用额外的类标记或类似标记，以便它可以找到要替换的文本。 搜索引擎仍会将标记作为常规文本读取，因此这不应该成为问题。
性能方面：如果您只是将其用于标题（并且它们不是会更改每个页面加载的标题），那么浏览器中以及服务器磁盘上的图像缓存应该可以消除对性能的任何担忧。 只要确保正确设置 HTTP 标头即可！
I know that with sIFR, and I assume with FLIR that you perform your markup in the same way as usual, but with an extra class tag or similar, so it can find the text to replace. Search engines will still read the markup as regular text so that shouldn't be an issue.
Performance-wise: if you're just using this for headings (and they're not headings which will change each page load), then the caching of the images in browsers, and also presumably on the server's disk should remove any worries about performance. Just make sure you set up your HTTP headers correctly!
由于 FLIR 是图像，而 sIFR 是闪存，我想使用 sIFR 会消耗更多的资源。 我还没有进行任何测试，但这似乎是合乎逻辑的。
搜索引擎搜索 sIFR 比 FLIR 更好，因为某些搜索引擎可以进入 Flash 文档的文本
since FLIR is IMAGES and sIFR is flash i would imagine that it would be a bit more resource intensive to use sIFR. I havent run any tests but it seems logical.
Search engines search sIFR better than FLIR because some search engines can go into the text of a flash document
我对 sIFR 不太了解，因为 FLIR 有效，而且我“感觉”它比 Flash 更好。 只需查看 sIFR 3 beta 演示页面 我注意到它似乎并不对浏览器首选项文本大小调整做出反应。 也就是说，我增加了 Firefox 中的字体大小（ctrl-+）并重新加载页面，标题保持相同的大小。
对于那些了解 sIFR 的人来说，这是脚本的实际限制还是他们只是做错了演示页面？
如果它实际上不能处理这个问题，我认为这是 FLIR 的一个主要优势，它确实以这种方式工作。 不使用屏幕阅读器的视力受损的人可能不会意识到文本不会根据他们的喜好调整大小。
也就是说，快速浏览一下 sIFR 的 API，您应该能够在 sIFR 中调整大小后的文本。 我认为这是一个需要修复的错误，而不是该方法的本质缺点。
I don't know much about sIFR because FLIR worked, and it "felt" better to me than Flash. Just looking at the sIFR 3 beta demo page I noticed that it doesn't seem to react to browser preference text resizing. That is, I increase my font-size in Firefox (ctrl-+) and reload the page, the headings stay the same size.
To those who know sIFR, is this an actual limitation of the script or did they just do the demo page wrong?
If it actually doesn't handle this, I'd call that a major advantage for FLIR, which does work this way. People with impaired vision who don't use screen readers probably don't appreciate that the text doesn't resize to their preference.
That said, from a quick glance at sIFR's API, you should be able to make resized text work in sIFR. I'd consider it a bug to be fixed, not an essential disadvantage of the method.
Woff 文件是最好的解决方案。
http://www.fontsquirrel.com/tools/webfont-generator
Woff files is the best solution.
http://www.fontsquirrel.com/tools/webfont-generator