Web 响应图像综述

WebKit 每日构建版本现在支持图像元素的 W3C srcset 属性规范，允许开发人员为拥有高分辨率显示器的用户指定更高质量的图像，而又不妨碍没有高分辨率显示器的用户。它还为尚不支持该特性的浏览器提供了一个很好的后备方案：

 
<img alt="My reakfast"
src="breakfast.jpeg"
srcset="breakfast-HD.jpeg 2x, breakfast-phone.jpeg 100w, breakfast<br></br>-phone-HD.jpeg 100w 2x">

WebKit 支持 CSS 函数 -webkit-image-set 已经有段时间了，它与 srcset 属性非常相似，可以为包含图像的 CSS 属性提供一个候选图像的 URL 列表，每个 URL 的后面都有一个修饰符，如“2x”。这样，浏览器可以为用户设备选择最好的图像：

 
body {
background: -webkit-image-set( url('path/to/image') 1x, url<br></br>('path/to/high-res-image') 2x ); 
}

WebKit 采取这一行动的时候，社区和浏览器实现者还在争论“什么是 Web 响应图像的最佳选择”。响应图像社区组织（RICG）将在数周后齐聚巴黎，讨论响应图像的前进方向。在召集会议时，RICG 的 Yoav Weiss 概括了响应图像未来的潜在解决方案和当前开发人员的实践：

过去的几年里，在 Web 开发人员的极大关注下，各团体的成员都致力于寻找一种方法为 Web 带来响应图像。虽然现在有三种待讨论的方案（srcset[1]、[2] 和 client-hints[3]），但是由于无法预知浏览器实现的必然趋势，所以我们宁愿让市场来决定哪一种解决方案能最有效地满足应用场景。

与此同时，Web 开发人员不得不自定义 polyfill, 这经常会阻止浏览器加载图像资源，直到 DOM 加载完成（至少是部分加载完成），并且页面上的 JavaScript 已经运行。这直接阻碍了浏览器工程师多年来一直从事的性能工作，包括优化资源加载和根据优先级尽快取得线上请求。上述情况使开发人员陷入了两难境地，“我们是延迟图像加载呢，还是下载不必要的图像数据而导致整个加载时间延长进而夸大了用户账单呢？”

为应对 Web 响应图像的挑战，当前流行的解决方案包括：

• Picturefill ：一个 polyfill，模拟已拟定的元素
• HiSRC ：一个 jQuery 插件，在页面加载的时候，根据设备支持情况，选择下载（或不下载）高分辨率的版本
• “自适应图像（ Adaptive Images ）”：一个服务器端解决方案，用于提供正确的图像分辨率 / 尺寸

查看英文原文： Round-up on Responsive Images for the Web