一年多来，我一直在密切关注正在进行的关于图片的讨论&思考图片如何在网络上“发挥作用”，做什么，以及应该如何“工作”。我在这里和那里写了一些关于这个主题的文字；最近我把一些体现这些思想的代码放到了世界上：scalables.js。
页面上图像的呈现大小主要取决于页面布局，而不是文件的固有尺寸。
我的老板扎根于印刷设计。每当他问我一张数字图像有多“大”时，我必须告诉他两件事：A和以英寸为单位的物理尺寸。“1200×900”可能是对文件数据的一个简洁而真实的描述，但在与老板交谈时，我必须将其转换为任意的物理大小：“300时为4˝×3˝。”当然，文件本质上没有什么是4˝×3˝的，它也没有“有”300；它同样可以在6˝×4.5˝的200时渲染，在1200时以1˝×3/˝的速度渲染，依此类推。
用“-像素”代替“英寸”，用一些“@2x”声明代替数字，这是一个关于响应图像和围绕它们的大部分混淆的段落。
回到过去，当一个像素等于一个设备像素，我们都设计了固定宽度的布局时，将图像的数据像素定制成我们知道该图像将在我们的布局上呈现的大小是非常有意义的。我们将表示大小烘焙到图像文件本身中，以便我们通过网络发送的数据像素的数量等于我们知道必须填充的设备像素的数量。数据像素==-像素==设备像素。我们以最高的效率提供了完美清晰的图像。
在我看来，“响应图像问题”是这样的：我们不再知道需要填充多少设备像素。
原因之一是，高屏幕使像素/设备像素比率变得可变。Srcset="；"；最初试图通过允许作者指定不同的文件以不同的比率使用来解决这个问题。
但是我们将用给定的图像填充的像素数也变得可变了。人们在比以往任何时候都更大更小的设备上查看网络，由此导致的向流畅布局的转变意味着，除了不知道设备像素构成了多少像素之外，我们现在也不知道给定的img>；在我们的布局中将占据多少像素。
我们的三个像素-数据、和设备-已经解耦。像素不是像素不是像素。
似乎每个人都同意，除非浏览器学会愚蠢地处理一种新的格式，这种格式要么包含多种分辨率的图像，要么完全放弃传统的像素概念(顺便说一句：有人在做这件事吗？)，提供多个源文件以适应这种新发现的可能性是可行的。
但事实证明，创建一种机制来决定下载这些来源中的哪些-通过网络发送适当数量的数据(像素)-已经被证明是棘手的。
<；Picture>；和srcset="；"；都试图通过在中放置视口查询来解决第二个流体布局问题。这从根本上说是错误的，因为它要求作者根据特定的布局来定制这些查询，烘焙(不可见！太复杂了！容易出错！)。把表演性的信息转化成他们的。我在邮件列表上写了很多关于这方面的内容。简要地说：
标记不应该依赖于布局。在编写标记时，我不应该从视口大小开始工作-而是考虑影响图像大小的布局的每个方面。当我添加新断点、调整最大宽度或调整某些填充时，我的标记不应该中断。
我不应该声明我想要为1X设备上的800像素宽的视口加载的源也是我想要为2X设备上的400像素宽的视口加载的源。我不应该害怕将来不得不添加更多的标记，以支持大于2的设备像素比率。
这些都是症状--根本问题是我们明确地将表现性信息与我们的<；img>；联系在一起。图像源没有固有的设备像素比或视口最大宽度，就像它有4˝或300时一样。它只是一堆数据-一堆像素。
然后，我将随心所欲地调整<；img>；的大小，并将其留给其他人(也许有一天，浏览器？目前：scalables.js)评估图像在屏幕上占用多少设备(像素)，并让其他人决定为我加载哪个源文件。而不是这样：
<；img src="；200.jpg"；srcset="；400.jpg 448w，800.jpg 512w，200.jpg 896w，400.jpg 1x，800.jpg 512w 2x，400.jpg 896w 2x，800.jpg 2x"；/>；
<；图片&><；源媒体="；(最小宽度：56em)"；srcset="；400.jpg 1x，800.jpg 2x"；>；<；源媒体="；(最小宽度：32em)"；源媒体="；200.jpg 1x，400.jpg 2x"；>；<；Source srcset="；400.jpg 1x，800.jpg 2x"；>；<；img src="；200.jpg"；>；<；/Picture>；
(它们是等效的，取决于具体的[相当简单！]。我在我的电子邮件示例中概述的布局)，您可以使用scalables.js编写以下内容：
<；div data-scalable>；<；img src="；200.jpg"；data-width="；200"；data-high="；133"；<；p>；查看图像：<；a href="；800.jpg"；data-width="；800"；data-high=&#。A href="；400.jpg"；data-width="；400"；data-Height="；266&34；>；Half-size(400 X 266)<；/a&>；<；/p&>；<；/div>；
循序渐进的增强，做得好，是双向的：我们从基岩开始，延伸到星星。
让我们把那个加价拆分一下。“scalable”由一个具有data-scalable属性的父元素组成，其中包含一个缩略图<；img>；以及对一系列源文件的引用-不在<；source>；标记或srcset="；"；"；属性中，而是使用好的老式锚点-它们只是链接！缩略图和每个链接具有描述其中数据的维度的数据宽度和数据高度属性。