注：这篇文章发布于September 27th, 2011，作者是 Jason Grigsby
在我上一篇的博文“什么是移动优先的响应式Web设计”中，我提到了一个用来判别一个响应式Web设计是否是“移动优先”的标准，即这个设计是否有处理IMG标签的策略。
最近在国外关于一个Web设计的网站Smashing Magazine上的一篇文章总结了一些响应式Web设计技术，其中包括几个处理IMG标签的新的方法。因此，现在非常适宜深入挖掘一下这个问题以及可能的一些解决方法了。
为什么IMG标签是响应式Web设计的关键
如果你想要你的站点尽可能快地加载，你会想要传送比实际需要更大的文件。很多响应式Web设计给移动设备提供的图像是适合于台式机的，然后再让移动设备去修改图像大小。
在我的研究中，我发现几乎传送到移动设备上的图像几乎需要减掉文件大小的80%才与实际需要相符。
那么在响应式设计中，IMG元素有什么问题呢?不像CSS图片可以通过媒体查询语句为不同分辨率的屏幕提供不同的源文件，IMGs只有一个单独的源属性。
什么是响应式的图像
响应式的图像是使用HTML的IMG标签传送的图片，这些图片可以根据不同的屏幕大小而改变图片来源。可以有很多技术方法来实现响应式的图像设计。
就我所知，Scott Jehl第一个使用了响应式的图像这个短语来描述图像来源问题的javascript解决方案。他最近将响应式的图像定义为一个通用的术语，因此，我希望他不会介意我拓展了他对这个短语的定义，以便来描述在响应式设计中用来解决提供合适大小图像的问题的技术。
响应式的图像问题面临的挑战
有一些挑战是响应式的图像技术所普遍面临的。当我们来看已经提出的各种解决方案的时候，我们需要将这些问题记在脑海中。
最低标准：直接下载移动设备适用图像，无需多余下载
Scott Jehl为响应式图像设计提出了一个最小标准：
◆ 直接就下载适用于移动设备的图像
◆ 升级到大的图像时无需下载两个图像
这两个都是必须要达到的目标。
第一次下载页面的问题
任何一个依赖于客户端脚本来决定应该提供哪一个图像源的解决方案都会遭遇第一次下载页面的问题。当用户第一次访问一个站点的时候，服务器端并不知道应该提供多大的图片。
来自于Bryan Rieger的 Muddling Through the Mobile Web 中的图像, 由 wscullin摄影, 受 Creative Commons保护.
如果加入了可以加载合适大小图片的javascript代码，那么第一次下载页面时相关信息就可以通过cookies以及类似技术从用户端获得。在理论上说，对于接下来的请求，服务器端都知道应该在IMG标签中包含什么样的图像大小了。
第一次加载速度是非常重要的。一个用户第一次体验到的速度价格会决定他们对一个产品或者公司的印象。Google、Yahoo以及其他的一些公司都说过很小的速度差异就会对用户使用产品造成很大区别。
竞争条件(Rendering Race Conditions)
依赖于使用javascript调整图像来源属性的技术需要确保调整发生在图像请求开始之前。
浏览器开发者做了很多工作在来下载尽可能多的资源，这通常来说这是个好事。但是在响应式设计中，javascript代码需要在任何图像请求开始之前就解析出需要多大的图像。
很多早期的工作都是通过使用动态库标签(dynamic base tags)来做的。这在javascript代码是包含在head标签中时是很有效的，但是当使用外部javascript文件时就难以避免要下载两次图像。
几乎每一种客户端技术都需要对不同浏览器处理以及下载资源的命令有非常深刻的理解。或者更实际一点说，任何一种方法都要经过广泛测试。
内容分发网络以及缓存
当你通过同一个url分发相同大小文件时，你会碰到一个由CDN以及其他网络边缘的缓存引起的问题。如果第一个人是在手机上请求一幅图像，那么接下来的请求者就会看到在手机上显示最优的图片，即使他们试用的是台式机。如果想要避免这一点，就需要在策略中考虑CDNs。
未来友好的响应式图像
如果我们相信“将来会有很多我们不曾想象多的互联设备出现”，我们就需要考虑一下解决方案在未来友好的。除了现在所做的实验之外，我们需要考虑一个可以长期使用的解决方案可能是什么样子的。
比如说，很多早期的响应式图像解决方案考虑了两种图像大小：一个用来提供给台式机，一个用来提供给手机。但是，这两种图像大小能满足正在到来的各种设备吗?
另外，现在的很多解决方案只是解决了这个问题的某一个方面。他们可能通过客户端的改变来改变图像来源，但是，这却给开发者留下了一个问题，即如何去处理图像大小的改变。对于共享库来说，限制范围可以解决这个问题。
但是在我们考虑未来系统要怎样才能成功时，我们需要考虑我们想要从服务器端和客户端想要获得什么。
下面是我认为一个能长期适用的技术需要考虑的一些事情：
◆ 支持绝对图像大小的改变——我们不能预期到屏幕大小是多少。我们需要系统能自动处理图像大小改变，并且能支持特定页面的绝对大小改变
◆ 手工设计可以覆盖自动的图像大小改变——不是每一个图像都可以不失去图像含义而改变大小的。有时候对图像进行裁剪比改变它的大小会有更好的效果。自动化的工具需要支持人工覆盖。
◆ 需要支持高分辨率显示——当面对iPhone4以及其他一些有高分辨率屏幕的时候我们应该采用什么方案呢?我们要给处于一个低端连接的高分辨率机器提供高像素的图像吗?这是一个开放性的问题。
但是不论我们现在选择如何进行处理，很明确的一点就是屏幕分辨率会不断增加的趋势不会改变。至少，我们已经看到在台式机上会出现更高分辨率。
这意味着我们现在对大图像的定义对将来的设备来说可能太小了。如果记住这一点，可能需要系统能接受最高分辩率的图像——即使现在的设备并没有这样的分辨率——那么当新的有高分辨率的设备出现的时候，现有的技术才会适用。
◆ 连接速度应该是标准中应该考虑到的——如果我们能知道网络连接的情况，我们就能更容易解决图像大小问题了。我们需要一种更简单的方式来获得这个信息。
◆ IMG标签可以被替换吗?——所有的响应式图像解决方案都在试图处理现在的图像标签只有单一来源的问题。对于重新看待这个标签，已经有各种建议，看我们是否能找到一个长期的替换方案。
在Part 2中，我们将会对现有的响应式图像设计方案进行更详细的解析，看看哪一个是最有可能的。
原文：http://www.cloudfour.com/responsive-imgs/
扫一扫
6326
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
