摘要

  • W3C 2013 年 HTML 5.1 草案给 dialog 安排了 showModal()、对话框栈、顶层显示、文档阻断、自动聚焦与关闭返回值；同日的交互章节规定模态框之外的内容进入惰性状态。
  • 2014 年 HTML5 候选推荐和 2017 年 HTML 5.2 推荐规范沿着这套分工继续细化。现行 HTML 标准又把焦点与关闭请求讲得更细。

弹窗最容易做的部分是“看起来像弹窗”。一个白色方框，一层半透明黑幕，再来两个写着确认与取消的按钮，前端同事半小时便能搭起戏台。困难藏在观众的手指里。Tab 是否还会逛到幕后的导航？屏幕阅读器是否仍把背景的表单当作当前任务？点击到底落在哪层？如果这些问题没人管，黑幕只是一张照片。

2013 年 5 月 28 日的 HTML 5.1 草案给 dialog 的定义相当务实：应用里供人完成任务的一块区域。show() 可以打开普通对话框；showModal() 则把它放进文档管理的对话框栈，送到顶层，并阻断文档。浏览器开始担任门卫：知道哪间房正在谈话，也知道其余房间该稍等。

同一份草案的交互章节说明“阻断”意味着什么：模态框以外的节点变成惰性。写网页的人仍然决定问题、按钮和后续处理；浏览器负责维持谈话边界。以前每个网站都可能自己绑几段键盘事件来模仿这道门，做得好坏全靠运气。规范把门的位置画在了公共地图上。

门卫还得知道如何迎客与送客。2013 年文本允许对话框尊重 autofocus，让指定控件先接待读者；最上层对话框可以收到取消请求；close() 可以通过 returnValue 留下结果。假设问题是“删除收藏文章吗”，浏览器负责关门并把结果送回去，网站决定是否真的删除。两者混成一团，就容易出现按 Escape 却误触确认的荒唐事故。

2014 年 2 月的 HTML5 候选推荐保留了栈、顶层与取消处理。2017 年 12 月的 HTML 5.2 推荐规范又写明了对话框的聚焦步骤。这些日期记录的是规范文本的推进，不能拿来当所有浏览器同日完工的打卡表。它们揭示了同一个设计判断：弹窗真正的工作，是让一件事暂时排在其他事前面。

所以 show() 和 showModal() 差得远。侧边的检查面板可以开着，让读者继续翻看文章；删除确认则需要读者先做选择，后台的按钮暂时退场。两种窗口都能画圆角，都能投阴影，只有后一种请浏览器替它看门。网站必须自己判断什么时候有资格叫停读者。

现行 HTML 标准对初始焦点、关闭请求和返回值写得更细，还加入了 requestClose() 与 closedby 等较新的安排。它们属于此后演进，别塞回 2013 年的草案。沿着史料看，主线其实很简单：网页问话时，谁掌管门；问完以后，读者又如何回到原来的位置。

好的弹窗，门卫几乎隐形。读者回答完问题，继续看文章。糟糕的弹窗则每走两步便拦人一次，仿佛门卫按开门次数拿提成。