# 体验侧的新能力：让 Web 更像应用，也更可组合

<div class="grid grid-cols-3 gap-5 mt-8">

<div class="card-green">
<div class="font-semibold mb-3">HTML in Canvas</div>
<div class="text-sm op-70">把真实 DOM 内容放进 Canvas / 3D 场景，保留选择、翻译和可访问性等 Web 能力。</div>
</div>

<div class="card-blue">
<div class="font-semibold mb-3">View Transitions</div>
<div class="text-sm op-70">用更少的 JavaScript 做页面状态切换，让 Web 应用的过渡更自然。</div>
</div>

<div class="card-amber">
<div class="font-semibold mb-3">Navigation API</div>
<div class="text-sm op-70">用统一事件管理前进、后退和应用导航，为 SPA 和跨页转场打基础。</div>
</div>

</div>

<div class="mt-8 card-blue text-sm">
这些能力服务同一个目标：把 Web 的开放性、可访问性和应用体验放到同一条轨道上。
</div>

<!--
这一页讲体验侧的新能力。

Chrome 原文里有一个很有画面感的 demo：在一个 3D 房间里嵌入浏览器内容，同时还能选择文本、翻译内容、查找 WebGPU。这个 demo 背后对应的是 HTML in Canvas 这个方向。它想解决的问题是：当我们进入 Canvas、游戏、3D 或沉浸式场景时，不应该牺牲 DOM 的文本能力、可访问性和 Web 语义。

View Transitions 解决的是另一个常见问题：Web 应用切换状态时，经常感觉像“突然换了一页”。以前我们要写很多动画逻辑，或者引入动画库，才能让列表到详情、页面到页面的切换更自然。现在平台开始提供更原生的转场能力，帮助改善感知性能和连续性。

Navigation API 则解决导航管理问题。传统 History API 在复杂应用里会显得比较分散，前进、后退、页面切换和应用状态管理经常需要我们自己拼很多逻辑。Navigation API 的方向，是把这些导航事件统一起来。它和 View Transitions 配合之后，Web 应用会更像一个完整应用，而不是一堆页面拼接。

这一页不需要深入 API 细节。我们只要让听众理解：Chrome 不只在做 AI，也在继续补 Web 的应用体验能力。Agentic Web 是新方向，但 Web 作为应用平台本身，也还在继续变强。

讲完能力，我们最后要回到团队落地：这些东西今天应该怎么跟，哪些可以做，哪些不能急。
-->