摘要

  • W3C 2022 年首份公开 View Transitions Level 1 草案让浏览器捕获同一文档更新前后的视觉状态。网页负责更新真实文档，浏览器在独立的视觉层呈现过渡。
  • 2023、2024 年的 Level 1 文本细化了捕获流程、具名元素和伪元素；2024 年的 Level 2 草案把视觉交接扩展到跨文档导航。

读者在新闻首页点开一张卡片。卡片里的照片若能平顺地长成报道页的题图，视线就知道自己去了哪里。这个看似简单的动作，曾要求网站在页面里搭临时舞台：旧卡片还得活着，新报道也得出现，两套状态挤在同一份文档中，等动画结束再清场。为了让照片漂亮地走几步，文档结构先扮演了一场杂技。

W3C 2022 年 10 月 25 日的首份公开草案给浏览器安排了摄影师的工作。网页调用 startViewTransition()，交给它一个更新内容的函数。浏览器先留住旧状态的视觉画面，待函数把文档改成新状态，再捕获新画面。随后动画在独立的视觉层发生。旧场景作为一张临时照片继续出现在眼前，真实的页面已经换好了景。

这不是给网页找一个更花哨的淡入按钮。旧、新状态若一直作为真实元素并存，文档的阅读顺序、交互位置和辅助阅读都可能变得别扭。视觉捕获把临时舞台从真实内容里搬出去。网站仍要负责让更新函数写出正确的报道、图片和链接；浏览器只为换场保存可见的影子。摄影师可以拍摄上一幕，不能替编辑写下一幕。

2023 年 9 月 5 日的候选推荐文本把流程列得像舞台提示：捕获旧画面，暂缓绘制，运行更新函数，捕获新画面，建立过渡用伪元素，再恢复绘制并播放动画。默认效果可以是整个页面的交叉淡化。若编辑想让题图、标题分别移动，可以给元素指定 view-transition-name，再用 CSS 为这些画面安排各自的路线。公共舞台由浏览器搭，谁走到聚光灯下由网页选。

有了名字就要守秩序。同一状态里两个元素争用同一个过渡名，视觉效果可能中止。2024 年 3 月 28 日的候选推荐草案进一步写明捕获树、调用过程和几个表示进度的 promise。动画跳过时，网页的更新函数仍会执行。这个安排抓住了主次：真正要送达读者的是新内容，漂亮的过场只能帮它开门。把过场当成内容更新本身，就像以为落幕的音乐能自动把演员送到正确的舞台。

W3C 发布历史记录了 2022 年首稿、2023 年候选推荐阶段及 2024 年修订。这几次文本围绕同一笔账：浏览器短暂保存两幅视觉状态，比网站长期养着两份真实界面更合算。开发者有自己的设计决定——哪些元素具名、动画多快、读者最终看到什么。浏览器负责在绘制层让换场看起来连贯。

下一道门更大：如果读者真的从一个文档走到另一个文档呢？2024 年 11 月 13 日的 Level 2 工作草案把模型带入跨文档导航，要求参与的页面按相应规则接上视觉交接。Level 1 处理同一文档里的状态更新；Level 2 处理导航两端的接力。两者都靠浏览器保留画面的能力，但换乘地点不同。

读者最后评判的不是伪元素树，而是自己点中的那张照片是否带到了想看的报道。顺畅的运动能把一次状态变化讲明白；若目的地空洞，流畅只会让失望更快抵达。浏览器替上一页拍好告别照，网站仍得把下一页办成一篇值得读的文章。