dialog 的 closedby 属性怎么控制关闭方式

closedby 决定原生

closedby 实际控制的是三类动作

这个属性不是“是否允许关闭”的总开关，而是给关闭来源分组。开发者指定的 dialog.close()、requestClose()、form method="dialog" 或按钮命令属于显式机制；平台关闭请求通常是用户按 Esc；light dismiss 则是用户点击或触摸对话框外部区域。

三种值可以先按下面的清单选择：

用三组 dialog 写出清晰的关闭策略

下面的示例只展示属性和显式按钮，打开方式仍由 JavaScript 控制。代码中的注释保留了每个值的产品语义：

打开设置



    显示密度 紧凑
    取消
    保存
  
这里放可被用户重新打开的帮助内容。
  关闭
图片预览
  关闭预览

如果项目还要兼容没有 Invoker Commands API 的环境，按钮可以绑定 dialog.close()；关键不是写法是否声明式，而是让每个 dialog 都有一条用户看得见、键盘和触摸设备都能使用的退出路径。

默认值会随打开方式变化

没有写合法 closedby 时，使用 showModal() 打开的 dialog 按 closerequest 处理，所以通常可以按 Esc 关闭；使用 show() 打开的非模态 dialog 则按 none 处理。不要把默认行为当成产品契约，重要流程应显式写出属性：

const dialog = document.querySelector("#settings");

// showModal() 建立模态上下文，显式属性仍负责表达关闭边界。
document.querySelector("#open-settings").addEventListener("click", () => {
  dialog.showModal();
});

// close() 只负责执行开发者指定的关闭，不会替代表单校验或保存逻辑。
dialog.addEventListener("close", () => {
  console.log("dialog 已关闭，返回值：", dialog.returnValue);
});

这里的 showModal() 会让对话框外部变为不可交互区域，但它不等于允许外部点击关闭。是否 light dismiss，仍要看 dialog 的属性和浏览器对该能力的支持边界。

把可访问性和异常关闭一起纳入清单

每个 dialog 都应有显式关闭按钮，模态场景可以给初始焦点设置 autofocus。不要给 dialog 本身添加 tabindex，焦点应落在对话框内部真正可操作的元素上。对于必填表单，普通的 method="dialog" 提交仍可能先经过约束校验；取消按钮可按需求使用 formnovalidate，或者由 JavaScript 明确调用 close()。

最后检查三个问题：外部点击是否会丢失未保存内容；Esc 是否会让用户困在模态流程中；移动设备没有物理键盘时，是否仍有可触摸的取消或关闭按钮。能回答清楚，再决定把边界放宽到 any。

常见问题

closedby="none" 会阻止 dialog.close() 吗？

不会。它限制的是用户动作来源，开发者指定的 close()、表单关闭或命令仍可执行。

closerequest 和 any 的主要区别是什么？

closerequest 接受 Esc 等平台关闭请求；any 进一步接受点击或触摸对话框外部的 light dismiss。

为什么不直接依赖 showModal() 的默认行为？

默认值会随打开方式变化，且产品意图不够明显。对重要流程显式写 closedby，更容易维护和审查。