摘要

  • W3C 于 2019 年 12 月发布的 Web Share 首份公开草案，让网页交出标题、文字或网址，由用户代理呈现目的地供读者选择。
  • 2023 年 5 月的推荐标准写入文件分享、canShare() 检查和用户操作条件，分享菜单仍属于设备与读者。

一个网页如果想让人转发文章，最笨的办法是给每一家通信服务都摆一只按钮。桌面上的按钮越排越长，手机上的空间越挤越小；读者常用的那个去处却可能根本不在名单上。编辑替读者猜朋友住哪条街，猜中了才算新闻送达，这生意怎么看都奇怪。

手机本来就知道自己的分享去处。它装着哪些应用，有没有邻近设备，能不能把内容存到某处，网页既不需要知道，也没有一张永远准确的清单。Web Share API 的办法像把柜台分成两边：网站写好包裹上的信息，设备叫出自己的选择界面，手指最终落在哪个选项上，由读者说了算。

W3C 于 2019 年 12 月 17 日发布的首份公开工作草案用一个简洁的调用说明这件事：网页在按钮触发时向 navigator.share() 交出标题和网址等资料，用户代理随后提供目的地选择。那份草案讨论标题、文字和网址。网页能发起请求，却不用扮演通讯录管理员，也不用调查手机里装了什么。

这道边界使分享按钮比一排品牌图标耐用。读者今日偏爱聊天应用，明日可能只想把链接存进自己的笔记。网页交出的仍是那篇文章的地址和说明。去哪儿由当时的设备界面和读者决定。出版物少操一份心，读者也少被迫走一条编辑预设的路。

到2023 年 5 月 30 日的 W3C 推荐标准，包裹可以装入文件。规范中的示例把 File 放进 files 数组；navigator.canShare(data) 可先检查资料是否适合分享。这个检查像柜台员先看看包裹尺寸，免得等顾客排队时才发现塞不进去。真正打开目的地界面的仍是 share()。

调用分享还要有用户操作。最常见的情形是读者自己按下按钮。规范也描述浏览器对同时进行的分享请求和取消操作的处理。于是一个认真做事的网页会在适合的设备上提供按钮，送出准确的标题与网址，并在读者关掉菜单后安静回到文章。关掉菜单也是选择，不该被网页写成一桩事故。

推荐标准谈到的目的地可以是应用、网站或联系人，具体菜单依赖环境。某部手机弹出一张分享表，另一部设备可能画出不同的窗口。标准没有许诺一幅世界通用的菜单截图；它规定的是网站如何把资料交给用户代理。柜台可以换装修，交接动作要清楚。

W3C 的发布历史把时间线摆得很明白：2019 年的首份公开草案，2023 年的推荐标准。文件资料与预检办法进入后来的成熟文本，核心分工却仍能用一句日常话讲清：网页把信写好，读者自己选邮筒。

对出版者而言，这也关乎文案诚实。分享时显示的标题若与落地页面风马牛不相及，设备的漂亮菜单也救不了那封信。网址若指向读者没打算送出的内容，问题出在打包的人。Web Share API 让交接更顺手，也让交接前那一小段文字更值得认真写。

分享界面最终像一扇门厅里的灯。它照亮可走的门，却不会替人决定拜访谁。网站站在门外，手里捧着链接；决定抬脚的始终是读者。