摘要

  • W3C 于 2013 年 12 月发布 Web 应用清单的首批公开草案，把名称、图标和首选启动地址放进由 HTML 链接的 JSON 文件。
  • 2026 年的 W3C 工作草案进一步区分短名称、启动 URL、导航范围、显示偏好和稳定身份；浏览器按照设备环境呈现这些信息。

浏览器标签里的网页有标题，有时还有一枚小小的站点图标。把它放到手机主屏幕，问题立刻变得像物业登记：门牌下写什么名字？图标用哪张？手指点进去，从哪个房间开始？用户明天还能认出它吗？每个问题都很小，几万个网站各写一套答案，就成了系统问题。

网站知道自己叫什么，浏览器知道设备怎样显示图标，用户知道主屏幕还有没有空位。把网站这边的资料集中到一份文件里，可以让三方少猜几次。HTML 页面给出清单链接，浏览器读到一份成套的介绍，再按自己的界面规则处理。网站可以申请门牌，住户仍有权决定要不要把它钉在门上。

W3C 在 2013 年 12 月 17 日发布的首批公开草案名为 Manifest for web apps and bookmarks。它设想一份保存 Web 应用元数据的 JSON 文件，并用 HTML 的 rel="manifest" 把页面与文件关联。草案摘要列出应用名称、图标与首选启动 URL；示例还描绘了用户把网站放上设备主屏幕的情景。网页第一次像要交一份可以机读的入住申请。

那张早期申请表的词汇与今天不同。2013 年的例子写着 name、url、mode: standalone 和 icons。它是尚在形成中的草案，具体字段后来经过修改。回头读，最重要的愿望却一眼可见：网页离开标签页以后，仍能带着自己的名字和入口被认出来。浏览器不必根据站点各处散落的线索拼出一张脸。

W3C 2026 年 10 月 16 日的工作草案展示了更细的名片。清单可以写 name 与 short_name，提供 icons，指定首选 start_url，划定 scope，表达 display 偏好，并用 id 标记应用身份。完整名称适合空间宽裕的界面，短名称适合图标下方。图标让人用眼睛认门。启动地址指出希望从哪里进，范围说明进入以后哪些路径还算这间屋子。

短名称听上去像小事，直到一个十二字站名被塞进主屏幕图标下的两行小字。编辑给它准备一份更利落的写法，读者才容易找到。图标同样需要维护；网站改了名字却留下旧图标，就像换了店招仍用昨天的门铃。清单给发布者一个整理这些细节的地方，也给浏览器一个明确的资料来源。

start_url 是首选入口。2026 年草案让用户代理决定如何对待这项偏好，也允许它把入口选择交给用户。网站可以在申请表上画箭头，楼管仍负责开门。id 则把应用身份与启动页面分开：一个服务日后搬动首页时，可以保留稳定身份。门牌是门牌，门后第一间房是另一回事。

scope 画出导航边界。它描述哪些 URL 属于该应用的上下文，浏览器在越过边界时可以改变呈现方式。这迫使网站认真回答“我们到底到哪里为止”。同一域名可能放着账户、帮助、商店、论坛；它们是否都在从图标打开的体验里，属于发布者要维护的地图。范围画得含糊，读者就不知道自己何时已经走出了原来的房间。

display 写的是希望如何呈现。草案列出不同显示模式供用户代理处理，网页递交偏好，浏览器按自身环境执行。真正占据主屏幕的那个方格则属于用户。这个分工很普通，也很重要：一份 JSON 文件可以让软件明白网站的自我介绍，不能替人决定手机上应住进哪些网站。

W3C 官方发布历史从 2013 年首稿延伸到 2026 年工作草案。文件版本一再变化，因为网页脱离标签页后的身份需要持续打理。一个人今天记住了图标，明天点开就应该还能回到熟悉的服务；起始页搬家时，也应能认出同一位住户。

清单的价值因此格外朴素。它让网页在请求一个新入口时，带上完整、可读、能更新的资料。浏览器接得住，用户看得懂。前台终于不用猜这位来客究竟叫什么。