此页面由 Cloud Translation API 翻译。

关于视图转换的误解

Bramus

View Transition API 为 Web 开发带来了颠覆性变化。无论您的网站是单页还是多页，此强大的 API 都可以让您在视图之间实现无缝过渡，从而打造出如同原生态一样令人着迷的体验。目前适用于 Chrome 浏览器，Safari 浏览器很快也会支持相同的文档视图过渡效果。

随着越来越多的人开始使用 View Transition API，您需要破除一些误解。

误解 1：View Transition API 截取屏幕截图

运行视图转换时，API 会拍摄内容的新旧状态的快照。然后，这些快照会添加动画效果，详情请参阅文档的“这些转换的工作原理”部分。

虽然您可以使用“屏幕截图”一词作为旧快照，但新快照不是屏幕截图，而是节点的实时表示形式。将其视为被替换的元素。

::view-transition
└─ ::view-transition-group(root)
   └─ ::view-transition-image-pair(root)
      ├─ ::view-transition-old(root) 👈 Screenshot
      └─ ::view-transition-new(root) 👈 Live representation

得益于这种实时呈现的特点，类似这样的演示发挥了作用：在视图过渡期间，来自新快照的视频可以继续播放。

正在播放观看过渡效果极简演示的视频。来源。

我们的文档中详细介绍了用于实现这一点的逻辑和 CSS。

误解 2：捕获多个元素会导致同时运行多个视图过渡

拍摄多个元素时，拍摄过程会捕获所有新旧状态。除 :root 元素之外，如果您捕获 .box，则会获得以下伪树：

::view-transition
└─ ::view-transition-group(root)
|  └─ ::view-transition-image-pair(root)
|     ├─ ::view-transition-old(root)
|     └─ ::view-transition-new(root)
└─ ::view-transition-group(box)
   └─ ::view-transition-image-pair(box)
      ├─ ::view-transition-old(box)
      └─ ::view-transition-new(box)

虽然此树包含多个快照对，但只会运行一个视图过渡。

目前，对于每个文档，Chrome 只能同时运行一个视图转场效果。尝试快速点击此演示，开始新的视图过渡。您会发现，当新的转换开始时，正在进行的转换会跳至末尾。

误解 3：由于浏览器支持，您无法实现视图转换

许多开发者担心无法实现视图转换，因为只有 Chrome 才支持这种转换。好消息是，Safari 正在开发这一功能，并将在即将发布的 Safari 18 版本中纳入这项工作。

不过，不要让稳定的浏览器支持妨碍您立即实现视图转换。视图过渡效果非常适合用于渐进式增强。原始文档介绍了将此方法添加到代码中的方法。

function handleClick(e) {
    // Fallback for browsers that don't support this API:
    if (!document.startViewTransition) {
        updateTheDOMSomehow();
        return;
    }

    // With a View Transition:
    document.startViewTransition(() => updateTheDOMSomehow());
}

如果您的浏览器支持同文档视图过渡，您将获得丰富动画版本。如果您的浏览器不能正常运行，您将只能获得当前体验。随着时间的推移，有越来越多的浏览器支持视图转换，将有更多用户能够自动体验这一丰富版本。

这同样适用于跨文档视图转换。如果浏览器不支持 CSS，则会在解析样式表时忽略 CSS 选择启用设置。

此方法已成功应用于电子商务，此案例研究对此进行了详细介绍

误解 4：视图过渡会破坏增量渲染

有声明视图过渡会破坏增量渲染。事实并非如此：跨文档视图转换被指定为不会破坏网络的这一基本方面。

当浏览器拥有“足够”内容时，就会开始呈现页面。在大多数浏览器中，这是指在加载 <head> 中的所有样式表、解析 <head> 中所有阻止呈现的 JavaScript 并加载足够的标记之后。跨文档视图转换不会改变这一点：First Contentful Paint 所需的内容保持不变。在第一次呈现后，浏览器可以并且以后会逐步呈现新收到的内容。

您可以选择阻塞渲染，直到 DOM 中出现特定元素为止。如果您想确保参与视图过渡的元素出现在新页面上，这会非常方便。

为此，请使用以下链接标记：

<link rel="expect" blocking="render" href="#elementId">

这会覆盖浏览器用来确定何时执行首次渲染的启发式算法：首次渲染会延迟，直到指定的元素在 DOM 树中出现。

这种手动屏蔽功能内置了一些保护措施。例如，如果能看到 </html> 结束标记但没有看到阻塞元素，系统将不再阻止呈现。此外，您还可以添加自己的超时逻辑，以随时移除屏蔽属性。

显然，您应谨慎使用阻塞渲染。您需要根据具体情况评估阻塞渲染的影响。默认情况下，避免使用blocking=render，除非您可以衡量对效果指标的影响，从而主动衡量和评估该功能对用户的影响。

误解 5：快照过程缓慢或成本高昂

当 View Transition API 准备新视图并获取其快照时，旧视图对用户仍然可见。因此，与不使用视图过渡效果相比，用户查看旧页面的时间会略长一些。但这种延迟可以忽略不计，实际上，这种延迟只有几个帧。例如，在 Chrome 中，pageswap 的影响最多为两个过时帧：一个用于执行逻辑，还有一个额外的帧，以确保已合成和缓存快照。

此外，快照的数据直接从合成器获取，因此无需执行额外的布局或重绘步骤即可获取快照数据。

额外的误解：这个 API 是 View Transitions API

谈到视图过渡时，人们通常会提到“View Transitions API”。这是不正确的。该 API 称为“View Transition API”，请注意单数“Transition”。

这种误解源于一些文章，甚至一度使用了我们自己的 DCC 文档 - 使用了错误的术语。

记住正确名称的技巧是使用（一个）View Transition API 来创建（一个或多个）视图过渡。