摘要

  • 2013 年 2 月，W3C 与 Responsive Images Community Group 合作推出了 picture 元素及响应式图片用例的首批公开草案。
  • 如今的 HTML 用 srcset、sizes 提供不同尺寸的候选文件，用 picture、source 和 media 条件处理需要改变构图的场景。

一张好看的大照片，经常有意留出大片空白。海面、云层、山坡，让角落那座灯塔显得孤零零，却也因此成为主角。把同一张照片塞进手机，海天仍占着位置，灯塔只剩几个红色像素。浏览器完成了缩放任务，图片编辑的任务却没人接。读者看见了海岸，找不到故事。

网页布局很早就学会随屏幕变宽变窄。列数可以改，字号可以调，图片地址却往往只写在一个 img src 里。脚本当然能事后换图，但浏览器读取页面时就想尽早发起图片下载。若编辑打算让窄屏换一张特写，最好在浏览器开始行动前，先把选择摆上桌面。

W3C 在 2013 年 2 月 26 日宣布两份首批公开工作草案。一份讨论 picture 元素，一份梳理响应式图片的需求。两份文件都与 Responsive Images Community Group 共同推进。这个组合很有出版人的习惯：先问图片究竟出了什么问题，再问标签应该怎样写。

当年的 picture 草案把它描述为一种根据 CSS 媒体查询决定图片来源的容器。候选图片与使用条件出现在 HTML 标记中，浏览器解析页面时就能读到。那是工作草案，细节尚在推敲；它提出的分工已经清楚：发布者提供候选画面和条件，浏览器根据当前环境作出选择。

W3C 同年 11 月整理的用例文件把经常混在一起的两件事拆开。第一件是分辨率：画面内容一样，只需为不同显示密度和排版宽度准备大小合适的文件。第二件是构图：横幅里的人物到了窄屏可能小得无法辨认，此时要换一个更近的取景。灯塔也一样。给远景照片增加像素，只会得到一座更加清晰、但依然微小的灯塔。

WHATWG 现行 HTML 图片章节分别给这两件事留了位置。对于同一构图的多个文件，img 上的 srcset 可以列出像素密度候选。若图片显示宽度随视口变化，宽度描述符配合 sizes 告诉浏览器页面预计给图片留下多少空间。浏览器再结合屏幕密度、缩放等条件，从作者提供的资源里选取文件。编辑列菜单，浏览器负责看桌子有多大。

需要换构图时，picture 里可以放多个 source。每个来源可以附上 media 条件与候选图片；浏览器按顺序查找，采用第一个符合条件的来源，再从它的候选文件中挑选。嵌在里面的 img 仍然是实际的图片元素，也承担后备显示。宽屏提供整片海岸，窄屏提供灯塔特写，决定画面的人在上传图片之前就完成了剪裁。

两种选择还能叠在一起。手机端的特写可以有几个不同分辨率，桌面端的远景也可以如此。先确定要呈现哪一种构图，再确定该构图使用哪一个文件。这个顺序听起来像图片部的常识，在网页上却曾需要一次标准化的争论。否则，一个站点可能郑重其事地准备四份远景，读者在四种清晰度里都找不到灯塔。

img 的替代文字也属于这份编辑工作。图片所表达的主角与作用，应当能通过文字传给看不到画面的读者。多个候选文件可以有不同裁切，但它们在文章中承担的意义应当一致。响应式图片让视觉选择更细，也让描述文字更值得认真写。

回头看 2013 年的讨论，最有意思的地方并非新标签本身。网页的外框已经可以灵活折叠，图片终于有了在折叠过程中保住主体的办法。编辑决定灯塔该占画面多少，浏览器决定此时该下载哪一份。读者不必拿放大镜替标准补课。