为什么响应式图片如此困难

也许您一直在关注响应式图片的#热议话题？如果您不知道“响应式图片”是什么意思，它指的是在不同情况下提供不同的图片。如何做到这一点以及这些情况是什么，差异很大。

如果您没有跟上进度，这里有一些链接。Bruce Lawson 做了一个 年底报告。这提供了试图标准化解决方案的工作的良好历史记录。Mat Marquis 撰写了关于所有主要浏览器供应商现状（无共识）的 简洁摘要。Tim Kadlec 对 这种情况 做了一个很好的总结。Dave Rupert 也一直在 谈论它。

这里需要理解的一点是：所有这些讨论都集中在HTML 中的图片上。内容图片。

这个问题在 CSS 中得到了很大程度的解决。如果添加到页面中的图片不需要在标记中，则可以使用 CSS 中的媒体查询来处理条件并相应地更改图片。

/* Look ma, responsive images */

body {
  background: url(mountains-small.jpg);
}
@media (min-width: 500px) {
  body {
    background: url(mountains-medium.jpg);
  }
}
@media (min-width: 800px) {
  body {
    background: url(mountains-large.jpg);
  }
}

当然，有时图片确实需要在标记中。这就是<picture> 和 srcset 以及 srcN 都试图解决的问题。这是一项艰巨的任务。解决方案需要

• 仅提供一个最终的 src
• 具有语义化
• 可访问
• 向后兼容
• 适应艺术指导
• 适应我们认为重要的所有条件
• 适应我们现在甚至没有考虑到的未来条件
• 独立于任何其他语言/技术工作
• 为作者、标准人员和浏览器供应商人员所接受

为什么每个人都难以达成一致？没有人参与其中是怀有恶意的。没有人坐在黑暗的城堡塔楼里疯狂地笑着。没有人故意延迟解决方案。至少据我所知。

我怀疑问题在于浏览器供应商人员正在尝试

1. 对实施的难度进行有根据的猜测。
2. 对特定实施到位后的未来将会如何进行有根据的猜测。

而作者

1. 非常确定我们知道我们需要什么。
2. 关心我们项目中的需求，虽然我们关心整个网络，但对网络的视角较少。

而标准人员需要

1. 确保没有任何东西被破坏。
2. 满足尽可能多的需求。
3. 还要对特定实施到位后的未来将会如何进行有根据的猜测。

在他们进行所有这些猜测之后，他们会争论支持/反对提出的解决方案。存在分歧是有道理的，因为很难用数据来支持猜测。许多人只是在凭直觉行事。再加上自负和政治因素，它竟然发展到今天这样，真是令人惊叹。我反而对我们拥有网络标准感到震惊（敲木头）。

但我要偏离主题了。如果您现在马上需要响应式图片怎么办？因为，比方说，从理论上讲，有大量的设备正在加载网页，这些设备具有各种各样的屏幕尺寸、屏幕密度、屏幕颜色和互联网速度等。哦，等等。

即使您认为，去他的标准，我只是想现在做任何必须做的事情来解决这个问题。以下是选项

• 跳过src 属性，让 JavaScript 确定条件，注入src。我看到的 90% 的“新”响应式图片解决方案都是以某种形式¹。
• 让服务器参与进来。让一个包含条件数据的 cookie（或类似内容）可用。拦截 img src 的 HTTP 请求，检查条件数据，直接从服务器提供合适的图片。

这两种技术的现有解决方案，方法略有不同。我在 这篇文章 中为您提供了这些解决方案的指南。

并记住，基于标记的解决方案可能不是处理此问题的唯一方法。还有其他一些想法正在浮出水面，这些想法采用了完全不同的途径

• 也许新的图片格式可以从本质上帮助解决这个问题。
• 也许服务器可以以某种方式自动帮助我们。
• 也许新的协议可以提供帮助。
• 也许我们应该能够直接控制浏览器的预取行为。

当我们走上这些道路时，我们现在在 HTML 解决方案中遇到的所有#热议话题几乎肯定会发生。

所以，是的，很难。

---

¹ 如果您要创建另一个这样的解决方案，我恳请您将其设计成一个 polyfill，并使用已经具有一定发展势头的语法。