编辑资料时，需要一个阻止背景操作的弹窗；邮箱旁边的说明按钮，又只需要展开一小段提示。这两种界面都浮在页面上，但对焦点、关闭方式和背景交互的要求不同。以前写组件，要自己处理这些行为，再借助 Teleport、遮罩和 z-index 解决显示位置。

浏览器提供的 <dialog> 和 Popover API 已经接走了其中一部分工作。模态 dialog 可以让背景变为不可交互，popover 可以原生处理点击外部关闭；两者还能进入 Top Layer，绕开普通层叠上下文。到了 Vue 项目里，剩下的问题变成了另一组具体约束：父组件的 v-model 怎样和浏览器状态同步，Esc 关闭怎样回传，关闭动画结束前是否保留模态，以及原有 Select、Tooltip 能不能继续正常工作。

这篇文章以 Vue 3.5.44 的普通 VDOM 为实现基线，提供两个可运行组件，并比较组件协调动画和纯 CSS 动画的取舍。关于分层界面、::backdrop 与现代进退场动画的讨论，借鉴了大漠的《Web UI：用 dialog 和 popover 搭建分层界面》；示例、机制图和工程判断按当前规范重新组织，兼容数据核对于 2026 年 11 月 1 日。

浏览器已经负责了哪些行为

把一个 div 显示出来，只完成了弹窗的视觉部分。真正的模态还要限制背景交互、安排初始焦点、避免 Tab 进入背景控件，并在适当时机恢复焦点。非模态说明则通常允许用户继续操作页面，没有必要把背景一起锁住。

dialog 的模态与非模态

原生接口很短，打开方式却直接决定行为：

<button id="edit" type="button">编辑资料</button>
<dialog id="profile-dialog" aria-labelledby="profile-title">
  <h2 id="profile-title">编辑资料</h2>
  <form method="dialog">
    <button value="cancel">取消</button>
    <button value="save">保存</button>
  </form>
</dialog>

const dialog = document.getElementById('profile-dialog');
document.getElementById('edit').addEventListener('click', () => dialog.showModal());
dialog.addEventListener('close', () => console.log(dialog.returnValue));

showModal() 会打开模态 dialog，将它放进 Top Layer，同时让同一文档中对话框及其后代之外的内容变为 inert。这里的 inert 是浏览器对交互和可访问性的限制，不需要给背景节点逐个添加属性。通过 .show() 打开，或者直接设置 open 属性，则属于非模态显示，不获得同样的背景限制和顶层呈现。showModal 的行为

按钮上的 commandfor="profile-dialog" command="show-modal" 还可以声明式地打开模态 dialog；command="close" 可以关闭并传递按钮的 value。但这组属性的兼容门槛比 showModal() 高，Vue 组件没有必要为了减少一次方法调用，强制要求所有浏览器先支持它。按钮命令属性

popover 是显隐和顶层机制

点击展开的说明可以直接写成：

<button type="button" popovertarget="privacy-note">为什么需要邮箱？</button>
<div id="privacy-note" popover="auto">
  邮箱用于接收账户通知。
</div>

auto popover 默认支持点击外部、Esc 等轻量关闭行为；打开另一个不属于同一嵌套关系的 auto popover，也会关闭已有浮层。manual 则把显隐控制更多地交给作者，不能指望它自动处理同一组关闭行为。hint 是另一套用于提示类浮层的规则，支持情况需要单独检查，不能从基础 Popover API 推断。Popover API 的使用方式

popover 自身没有固定的组件语义。菜单、列表框、Tooltip、非模态说明对话框，都可能使用这项显示能力，但各自还需要正确的角色、键盘操作和焦点策略。HTML 标准里的菜单示例也明确把方向键导航留给作者实现。HTML 的 popover 作者说明

因此，本例把带交互按钮的说明面板实现成非模态 role="dialog"，没有把它叫作完整 Tooltip 或菜单。

Top Layer 改变绘制位置，DOM 仍在原处

Top Layer 是每个文档自己维护的顶层绘制集合，模态 dialog 和打开的 popover 可以进入其中。普通页面节点无论设置多大的 z-index，都不能压过顶层元素；多个顶层元素按进入顺序叠放。

图中左边的组件 DOM 没有搬家，右边才是简化后的绘制顺序。Vue 仍然管理原来的节点、插槽和事件关系，CSS 变量也继续按 DOM 继承。原生浮层通常不需要额外 Teleport 才能突破祖先裁剪，这正是它在框架中容易封装的原因。Top Layer 的定义

这个顶层属于当前 document。把示例放进 iframe 后，模态只覆盖并限制 iframe 内的文档，外层博客仍可操作；微前端 iframe 也不会因为内部调用 showModal 就拥有覆盖整个宿主页面的能力。

先操作一个 Vue 3 示例

示例包含独立 dialog、独立 popover，以及 dialog 内部的嵌套 popover。表单只更新当前页面内存，不发送网络请求。可以单独打开演示，也可以在下面的预览里操作；独立页面更适合观察完整的遮罩和焦点行为。

先打开 dialog，留空点击保存，再点击取消，比较表单校验与返回值。随后试 Esc、阻止 Esc、遮罩关闭和「关闭后 60ms 重新打开」。观察模型、DOM 状态和动画阶段，不必只靠肉眼判断窗口是否已经结束。

文章中的代码区用于阅读，下方预览运行同一份 Vue SFC 的 Vite 构建快照；修改组件时，在本地运行 pnpm dev，再用 pnpm build:playground 更新快照。它保留真实 Vue 运行时与全部交互，不依赖在线转译器重新编译 SFC。

需要迁入项目时，把源码包中的 copy/ 放到对应的组件和 composable 目录，并调整 import。组件要求 Vue 3.5+，因为使用了 useTemplateRef 和 useId；defineModel 本身从 Vue 3.4 开始提供。SCSS 由 Sass 编译器处理，本例固定为 sass-embedded。

完整源码、目录说明与检查方式见组件源码与本地运行方法弹窗。本地运行入口是源码包根目录的 pnpm install 和 pnpm dev，无需改博客主项目的依赖。

对业务页面暴露的接口可以保持熟悉的形状：

<script setup lang="ts">
import { ref } from 'vue';
import NativeDialog from './components/native-dialog/index.vue';
import NativePopover from './components/native-popover/index.vue';

const editing = ref(false);
const helpOpen = ref(false);
</script>

<template>
  <button type="button" @click="editing = true">编辑资料</button>
  <NativeDialog v-model="editing" title="编辑资料">
    <template #default="{ close }">
      <button type="button" @click="close('button', 'cancel')">取消</button>
    </template>
  </NativeDialog>
  <NativePopover v-model="helpOpen" label="保存说明" title="保存在哪里？">
    <p>关闭面板后，表单草稿仍由父组件保留。</p>
  </NativePopover>
</template>

v-model 与浏览器状态怎样同步

封装里存在两种不同职责的状态。v-model 表示调用方希望窗口打开还是关闭；dialog.open 和 :popover-open 表示浏览器当前的原生显隐状态。增加退出动画后，这两者可以短暂不同。

managed 模式中，模型变为 false 时，窗口开始退出；动画结束才调用原生关闭 API。这个阶段出现 v-model=false、dialog.open=true 是有意保留的过渡，背景也仍受模态约束。业务不能把「模型已经为 false」当作 DOM 已经移除，或原生焦点已经恢复。

由父层提供初值

组件使用必传 model，不另设一个初始为 true 或 false 的私有镜像：

const visible = defineModel<boolean>({ required: true });

父层用 ref(false) 初始化；组件通过这个 model 发出更新。defineModel 已经声明 model prop 和对应更新事件，不需要再重复声明一次 modelValue / update:modelValue。父子默认值分叉的情况可参考Vue 组件 v-model。

等 DOM 挂载后调用 API

下面是 dialog 源码里的 watcher；完整打开、关闭分支放在 synchronize 中：

// native-overlays/copy/components/native-dialog/index.vue:75-82，watcher 节选
watch(
  [visible, element],
  ([wantsOpen, dialog]) => {
    if (dialog) void synchronize(wantsOpen, dialog);
  },
  { immediate: true, flush: 'post' },
);

把模板 ref 也作为输入，可以覆盖「父层初始值已经为 true，但 dialog 还没有挂载」的情况；flush: 'post' 让回调在 Vue 完成本轮 DOM 更新之后运行。Vue 的 watcher 调度时机

模板上没有绑定 :open="visible"。直接写 open 会打开非模态 dialog，而且手动移除 open 不等价于执行 close 算法，不能替代原生 API。SSR 阶段也只输出稳定的关闭结构，真正的模态打开留在客户端挂载后完成。

浏览器也能改变状态

只做「watch 模型，然后调用 show / hide」还不够。用户按 Esc、点击 popover 外部、提交 method=dialog 表单，都会经过浏览器自己的路径，需要把结果接回 model。

dialog 监听原生 close，popover 监听 toggle。popover 的回调读取当时的 :popover-open，不会把每条历史通知机械重放为模型变化。原因是 toggle 会排队，并可能把同一轮里的多次切换合并；收到通知时，元素也可能已经经过更新的打开或关闭操作。toggle 的事件合并

dialog 也有迟到事件问题。同一节点执行 close 后马上又 showModal，旧 close 事件到达时，新的窗口已经打开。示例先检查 dialog.open，再决定是否同步为 false；每次打开还会重置返回值，避免上一次 save 被误认成这一次的结果。

关闭请求、关闭完成与表单结果

关闭不是一个统一入口。能否取消、有没有返回值、是否经过表单校验，取决于具体路径。

cancel 的可取消性与 requestClose 的行为见 MDN cancel 和 requestClose。因此，仅监听 cancel 并不能自动拦住 close、表单关闭和所有组件按钮。

示例提供的 @cancel 只承诺同步取消。若关闭前要弹出「是否丢弃草稿」或等待异步保存，需要先同步阻止本次关闭，再进入业务确认流程；异步结果回来后还要确认当前窗口、路由与请求仍然有效。不能在 cancel 回调里 await 结束后，才期待 preventDefault 追回已经执行的默认动作。

method=dialog 仍会执行表单校验

保存按钮使用 value="save"；取消按钮使用 value="cancel" formnovalidate。取消按钮需要跳过校验，否则邮箱为空时，取消也可能被 required 阻止。

<form method="dialog">
  <input name="email" type="email" required>
  <button type="submit" value="cancel" formnovalidate>取消</button>
  <button type="submit" value="save">保存</button>
</form>

这里的提交不会把表单发到服务端，但仍然经过浏览器校验。它返回的是触发提交按钮的 value，不是完整表单数据；真实保存需要业务自己的提交逻辑。完整机制和 required 示例见 dialog 表单关闭。

组件不会为了帮所有插槽关闭而额外包一层 form，因为插槽本身可能已经是表单。HTML 不允许嵌套 form，这类结构错误会影响实际解析与提交归属。form 的内容约束

两种动画分别保留了什么

给弹层加 opacity 和位移很容易，难点在于原生关闭会切换 display，并把元素从 Top Layer 移除。如果关闭后立刻通过 v-if 移除整个组件，视觉退出也没有可以继续绘制的节点。

纯 CSS 让原生状态先关闭

现代 CSS 可以把普通透明度过渡与离散属性配合起来。下面是简化后的 dialog 动画结构，完整样式还包含 backdrop 和减少动态效果分支：

dialog {
  opacity: 0;
  transform: translateY(12px);
  transition:
    opacity .2s,
    transform .2s,
    display .2s allow-discrete,
    overlay .2s allow-discrete;
}

dialog[open] { opacity: 1; transform: none; }

@starting-style {
  dialog[open] { opacity: 0; transform: translateY(12px); }
}

@starting-style 提供从 display:none 进入时的起点；display 过渡让退出期间仍能绘制；overlay 过渡推迟离开 Top Layer。overlay 的值由浏览器管理，作者的职责是声明过渡，不能像普通开关一样手动把 overlay 设成 auto 来创建顶层。Chrome 的进退场动画说明、MDN overlay

这条路径里，原生 close / toggle 可以先到达，像素动画随后才结束。@closed 表示原生显隐状态已经关闭，不承诺视觉退出也完成了。

组件协调让原生关闭发生在动画之后

managed 模式把表面动画放到 close() / hidePopover() 前面，使用 Web Animations 的 finished Promise 等待结束，而不是靠一个与 CSS 时长可能漂移的 setTimeout。新一轮操作会取消旧动画，并使旧完成回调失效。

图中上面一行在退出期间仍保持原生模态，下面一行先完成原生关闭，再由受支持的 CSS 保留视觉效果。两种时序都可以成立，业务需要先决定自己关心的是关闭意图、原生交互状态，还是像素动画结束。

动画中的快速重开尤其容易出错。假设旧关闭动画还有 140ms 才结束，用户已经重新打开；旧回调若继续执行 close，就会把新窗口关掉。示例用递增 revision 区分当前操作，新动画和卸载都会让旧 revision 失效；同时处理取消动画后 finished 的拒绝，避免产生未处理异常。Animation.finished

减少动态效果开启时，managed 路径直接完成状态切换，native 路径取消过渡。动画也不能成为唯一的完成通知，关闭后业务动作应依赖明确的组件事件或操作结果。prefers-reduced-motion

auto popover 的浏览器关闭不能统一等待

popover 在打开前的 beforetoggle 可以取消，关闭前的 beforetoggle 不可以。也不能在该回调里重入调用 showPopover / hidePopover，企图撤销正在执行的切换。beforetoggle 的可取消条件

本例因此明确区分两条路径：组件按钮或父层模型发起关闭时，可以先播放 managed 动画；Esc、点击外部或另一个 auto popover 导致的原生关闭，接受浏览器结果并同步 model，退出效果允许降级。需要所有关闭入口都平滑退出时，可以优先评估原生 CSS 动画的支持范围；改成 manual 后自行重建关闭和嵌套策略，则是另一项实现工作。

兼容性要按能力分别判断

「支持 dialog」不能推出支持 commandfor，也不能推出完整退场动画可用。下面是 2026 年 11 月 1 日核对的起始版本，Safari 列同时对应其 iOS 引擎基线；具体组合仍需要目标设备验证。

依据分别来自 MDN BCD 的 HTMLDialogElement、全局 HTML 属性、button、dialog、starting-style、transition-behavior 与 overlay。静态节选见本次兼容数据与判读范围弹窗。

Firefox 接受 allow-discrete 语法，不代表已经实现 display 过渡；因此 CSS.supports('transition-behavior', 'allow-discrete') 只能作为语法探针。示例也把这个限制直接写在能力检测面板里。

@property、oklch、backdrop-filter 则是另外几项增强。需要平滑动画的自定义颜色变量可以通过 @property 注册类型；普通遮罩、渐变和模糊不应该成为基础打开 / 关闭功能的前提。注册自定义属性

对旧内核，按项目需求选择保留已有组件、明确能力回退或引入 polyfill。JavaScript 转译不能补出浏览器的 Top Layer，dialog polyfill 也明确记录了层叠上下文限制。dialog-polyfill 的限制

正式使用时还需要处理什么

原生能力减少了基础设施代码，业务交互、定位和终端适配仍然需要应用负责。下面这些问题会直接改变组件边界，不能等到换完所有弹窗后才检查。

现有组件库的浮层可能在两个方向上冲突

原生 dialog 内的 Select、DatePicker 或 Tooltip，如果通过 Portal / Teleport 挂到 body，它们就可能处于模态背景，既被顶层遮住，又失去交互。调整普通 z-index 无法把它们提到原生 Top Layer；需要将对应浮层挂到 dialog 后代容器，并重新检查裁剪、键盘和焦点。

反方向也有问题：页面已有自定义 div 模态，再引入原生 popover，popover 可能覆盖自定义模态。Adrian Roselli 用超时警告与说明浮层演示过这种混用风险；那是特定历史浏览器中的案例，适合借来设计重叠场景测试，不应把录制结果写成所有当前组件库都存在的固定 bug。Popover 与自定义 dialog 混用的案例

Ant Design 可以检查 Tooltip 的 getPopupContainer，Element Plus 可以检查 Tooltip 的 append-to / teleported。调整挂载位置只解决一部分问题，还要确认原有焦点锁不会和浏览器模态策略互相争夺焦点。

定位需要独立设计

基础 popover 的默认样式接近居中弹框，不会自动变成贴着触发器的气泡。可以使用 CSS Anchor Positioning，并配合 position-try-fallbacks 做溢出翻转；它们的支持范围要另外核对。CSS Anchor Positioning

本例为了让基础 API 和状态流程在更宽的支持范围内运行，只实现了固定定位、上下翻转、横向边界限制，以及滚动、resize 和尺寸变化后的更新。它没有覆盖完整 placement 集合、RTL、虚拟锚点、所有布局位移和移动键盘变化。

需要这些能力时，复用 Floating UI 的 Vue 绑定通常更划算。Popover API 可以管理顶层与轻量关闭，定位库处理几何，两者可以协作。Manuel Matuzović 的原生 popover 定位示例也适合对照阅读，但其中对浏览器现状的描述要结合发布日期理解。

inert、滚动和移动键盘各有职责

模态背景不可点击，不等于背景滚动已经在所有环境中完整锁住。滚轮在 backdrop 上移动、内部滚动到边界，都可能把滚动传给页面。示例为 dialog 与 backdrop 添加了滚动链约束，但不会把它描述成全终端滚动锁。Chrome 对模态下页面滚动的说明

正式项目要用自己的长内容、嵌套滚动区和目标手机验证。窗口需要明确的最大高度与内部滚动范围；dvh 可以帮助适应动态视口，软键盘、缩放和可视视口移动仍是独立条件。页面出现横向位移时，还要核对滚动条占位，而不是只反复调整弹窗宽度。

焦点落点要按任务选择

邮箱表单把 autofocus 放在输入框上很自然，但长协议、复杂说明或危险确认不能照搬。长内容可能需要让读者先从标题开始；破坏性操作则不适合一打开就把焦点放到危险按钮上。打开模态时焦点放在哪里

popover 内的 autofocus 也会在打开时触发焦点移动，它不是「以后获得焦点时的优先提示」。popover 的区别在于没有模态焦点限制。Tab 离开 popover 也不会默认将它关闭；需要失焦关闭的菜单或选择器，要按该组件的语义增加行为，不能把所有说明面板统一改成失焦即关。Scott O’Hara 对 popover 默认行为的解释

键盘操作通过，也不代表屏幕阅读器已经完整验收。可访问名称、复杂内容的描述方式、触发器与浮层的关系、关闭后触发器已被删除的情形，都需要真实使用路径。原生 dialog 的 Tab 导航会避免进入背景控件，但用户仍能进入浏览器自身界面；不要额外拦截所有键盘导航来制造封闭窗口。

焦点恢复也以真实的原焦点为前提。在这份示例的 Playwright WebKit 检查里，鼠标点击打开时和先聚焦按钮、用 Enter 打开时，关闭后的落点不同；后者才能明确验证回到触发按钮。产品需要统一到某个业务入口时，应先确认平台策略与实际任务，不能只用一次鼠标点击的结果判断原生恢复是否失效。

auto、manual 与多个浮层需要明确策略

无关的 auto popover 通常互斥，合法嵌套可以同时展开；manual 可以并存，但轻量关闭与 Esc 等策略需要另外负责。面板里再出现菜单、全局消息或确认框时，要先定义哪个应该留下，哪个应该关闭，不能只根据 z-index 数值建立栈。

如果只是需要一个永远同时存在的小提示，把 auto 改成 manual 可能满足显示需求，但也会改变用户预期的关闭方式。对普通通知，还应判断是否真的需要抢焦点、是否要通过 live region 宣告，以及信息是否会过早消失。Popover 的可访问性分工

Vue 生命周期不止挂载与卸载

组件默认保留插槽 DOM，隐藏不等于销毁，表单值也不会自动清空。是否每次新建草稿、关闭后重置校验、保存成功后更新页面，应由业务状态明确决定。

路由切换、KeepAlive 停用和父层条件移除也有区别。示例覆盖卸载清理，但没有把 KeepAlive 停用扩展成完整的页面浮层管理；被缓存页面需要在停用时主动关闭或交给统一管理者。多个 Vue 应用共享一个 document 时，也要检查 ID 命名空间，而不只确认单个组件里用了 useId。Vue KeepAlive 生命周期

显示样式不能破坏隐藏规则

给 [popover] 无条件写 display: grid 或给 dialog 无条件写 display: flex，可能覆盖浏览器用于关闭状态的隐藏样式。需要改变内部布局时，可以把布局放在内部 surface，或把 display 限定在真正打开的状态上。示例采用内部 surface，也让内容动画与外层原生显隐分工清楚。web.dev 的 dialog / popover 样式说明

点击遮罩关闭也要区分手势起点。用户在弹窗内拖动选区，最后松手到遮罩上，不应因此丢失表单。示例要求指针按下和抬起都在弹窗外，并且不是仅凭 event.target === dialog 判断；dialog 自身的空白 padding 也属于窗口内部。

与 Ant Design、Element Plus、Tippy 怎样取舍

原生 dialog 和 popover 可以被 CSS 做成同样精致的界面，原生标签不会强制使用某种操作系统弹窗皮肤。比较时更有价值的是交互能力、浏览器覆盖和维护职责。

Ant Design Modal 和 Element Plus Dialog提供的不只是遮罩和居中，还包括异步确认、关闭控制、加载状态、销毁策略与设计系统配合。项目已经付出这些依赖成本时，替换基础标签不必然减少总维护成本。

Tippy则主要对应 Tooltip / Popover，拥有触发方式、延迟、触摸和定位配置，不能直接和模态 dialog 对比。它的仓库已于 2024 年 11 月 9 日归档，新项目还要考虑后续维护。

原生方案能减少自行维护的底层行为，但这份示例没有做组件库包体或性能基准，不能从示例文件大小推导「比 Ant Design 快多少」。采用价值应回到项目真正省掉了哪些工作，以及又新增了哪些适配责任。

验证范围与资料入口

示例使用真实 Vue SFC 编译，浏览器测试覆盖模型与原生显隐、表单校验和返回值、焦点恢复、嵌套 Esc、遮罩关闭、退出中重开、迟到事件、自动关闭互斥、卸载、移动宽度和减少动态效果。实际浏览器版本、检查结果和未覆盖范围见浏览器验证记录弹窗。

兼容表用于确认平台支持起点；自动化测试用于确认这份实现的具体行为。二者不能互相替代，Playwright 的 WebKit 也不能写成真实 iPhone Safari 的验收。

继续查资料时，可以按当前问题选择入口：

按官方规范、MDN、框架文档与作者实践分类的完整阅读索引见分主题阅读索引弹窗。第三方文章里的历史版本判断保留其时间背景，当前支持情况以对应能力的数据和实际终端为准。

总结

原生 dialog 把模态、顶层绘制和一部分焦点行为交给浏览器；Popover API 把非模态浮层的显示、轻量关闭和顶层关系变成平台能力。在 Vue 中，通过必传 model、挂载后的 API 同步和原生事件回传，可以把这些命令式接口封装成声明式组件。

接入后的主要工作集中在状态与时序。关闭意图、原生关闭和视觉退出是不同阶段；组件协调动画需要处理取消和重开，原生 CSS 动画需要独立评估 display / overlay 的支持，auto popover 的浏览器关闭又不能用不可取消的 beforetoggle 强行延后。

对新项目的小型弹窗和说明面板，这些能力很值得采用；对成熟后台、复杂定位和旧 WebView，迁移决定仍取决于嵌套浮层、滚动、焦点与目标用户。先选一个边界明确的组件接入，把原生能力真正省掉的工作验证出来，再决定是否扩大使用范围。

pnpm install
pnpm dev

<script setup lang="ts">
import { ref } from 'vue';
import NativeDialog from './components/native-dialog/index.vue';
import NativePopover from './components/native-popover/index.vue';

const dialogOpen = ref(false);
const helpOpen = ref(false);
</script>

<template>
  <button @click="dialogOpen = true">编辑</button>
  <NativeDialog v-model="dialogOpen" title="编辑资料" @closed="console.log($event)">
    <template #default="{ close }">
      <button type="button" @click="close('button', 'cancel')">取消</button>
    </template>
  </NativeDialog>
  <NativePopover v-model="helpOpen" label="查看说明" title="保存说明">
    <p>这里是补充信息。</p>
  </NativePopover>
</template>

pnpm typecheck
pnpm build
pnpm exec playwright install chromium
pnpm test:browser

{
  "checkedAt": "2026-11-01",
  "kind": "selected-fields-transcribed-from-mdn-bcd",
  "note": "这是核对时选取的字段，不是完整 BCD 仓库快照；preview 不表示正式版支持，mirror 按对应引擎解释。",
  "features": [
    {
      "name": "dialog.showModal",
      "chrome": "37",
      "firefox": "98",
      "safari": "15.4",
      "source": "https://raw.githubusercontent.com/mdn/browser-compat-data/main/api/HTMLDialogElement.json"
    },
    {
      "name": "popover",
      "chrome": "114",
      "firefox": "125",
      "safari": "17",
      "source": "https://raw.githubusercontent.com/mdn/browser-compat-data/main/html/global_attributes.json"
    },
    {
      "name": "command / commandfor",
      "chrome": "135",
      "firefox": "144",
      "safari": "26.2",
      "source": "https://raw.githubusercontent.com/mdn/browser-compat-data/main/html/elements/button.json"
    },
    {
      "name": "closedby",
      "chrome": "134",
      "firefox": "141",
      "safari": "preview",
      "source": "https://raw.githubusercontent.com/mdn/browser-compat-data/main/html/elements/dialog.json"
    },
    {
      "name": "@starting-style",
      "chrome": "117",
      "firefox": "129",
      "safari": "17.5",
      "source": "https://raw.githubusercontent.com/mdn/browser-compat-data/main/css/at-rules/starting-style.json"
    },
    {
      "name": "transition-behavior",
      "chrome": "117",
      "firefox": "129 (partial: no display transitions)",
      "safari": "17.4",
      "source": "https://raw.githubusercontent.com/mdn/browser-compat-data/main/css/properties/transition-behavior.json"
    },
    {
      "name": "display transition",
      "chrome": "117",
      "firefox": false,
      "safari": "18",
      "source": "https://raw.githubusercontent.com/mdn/browser-compat-data/main/css/properties/transition-behavior.json"
    },
    {
      "name": "overlay",
      "chrome": "117",
      "firefox": false,
      "safari": false,
      "source": "https://raw.githubusercontent.com/mdn/browser-compat-data/main/css/properties/overlay.json"
    }
  ]
}