渲染后的HTML看起来像这样:

\n    \n
\n\n

浏览器的支持比pictufill好得多，但代价是它是一个更实用的解决方案，而不是一个前瞻性的解决方案.

源洗牌

源洗牌 从与其他前端库稍微不同的角度处理响应式图像问题. 它类似于“移动优先”的思想流派, 因此，它在默认情况下提供尽可能小的分辨率. 一旦检测到设备有更大的屏幕，它就会将图像源交换为更大的图像. 它感觉更像是一个hack，而不是一个成熟的库. 这对于移动站点来说是一个很好的解决方案，但对于台式机和/或平板电脑来说，这意味着不可避免地要进行双重资源下载.

其他一些著名的JavaScript库有:

\n
• \nHiSRC 一个响应式图像的jQuery插件. 对jQuery的依赖可能是一个问题.
\n
• \nMobify.js -一个更通用的库响应内容，包括图像，样式表，甚至JavaScript. 它在资源加载之前“捕获”DOM. Mobify是一个功能强大的综合库, 但如果目标只是响应图像，则可能会过度使用.
\n

Summary

在一天结束的时候，这是由开发人员决定的 响应式网页设计 图像方法适合用户群. 这意味着数据收集和测试将为采取的方法提供更好的思路.

总结一下, 在决定适当的响应式图像解决方案之前，下面的问题列表可以帮助您考虑.

\n
• 旧浏览器是一个问题吗? 如果没有，考虑使用更现代的方法.g: Picturefill, srcset 属性)
\n
• 响应时间是否至关重要? 如果没有，请使用第三方或后端解决方案.
\n
• 解决方案应该是内部的吗? 第三方解决方案显然将被排除在外.
\n
• 网站上是否已经有很多图片正在尝试向响应式图片过渡? 是否担心验证或语义标记(或者更确切地说是非语义标记)? 这将需要一个后端解决方案将图像请求路由到自适应图像之类的东西.
\n
• 美术指导是个问题吗(特别是对于包含大量信息的大型图像)? 对于这种情况，像pictufill这样的库将是更好的解决方案. 此外，任何后端解决方案也可以工作.
\n
• 是否担心缺乏JavaScript? 任何前端解决方案都是不可能的, 这就留下了依赖于UA嗅探的后端或第三方选项.
\n
• 移动响应时间是否优先于桌面响应时间? 像Source shuffle这样的库可能更合适.
\n
• 是否需要为网站的每个方面提供响应行为，而不仅仅是图像? Mobify.Js可能效果更好.
\n
• 完美的世界已经实现了吗? 使用CSS-only 显示:没有 方法!
\n