仍在期待更好的原生页面过渡

如果我们愿意，能够在网页上对页面之间的过渡进行动画处理，而无需诉诸黑客手段或全面的架构选择来实现，那将是一件好事。我可以想象出一个 API，它可以在页面卸载之前运行某些东西，也许可以与 WAAPI 集成，并在下一个页面加载后运行其他某些东西。这将与常规的锚链接和页面加载相结合。

我们确实有一个 onbeforeunload API，但我不知道它有什么样的包袱。从技术上讲，我们现在可以构建页面过渡，即使没有单页面应用程序架构，但我要的是专门构建的 API，它们可以帮助我们干净地执行此操作（可理解的函数），同时考虑到性能（与正常点击链接一样快）和可访问性（如焦点处理）。

如果您正在构建单页面应用程序，则可以自由地在视图之间进行动画处理，因为页面永远不会重新加载。这里的危险是，您可能会仅仅为了这个功能而选择单页面应用程序，这就是我所说的为了实现这一点而不得不采用网站架构。这感觉就像一个不幸的权衡，因为单页面应用程序带来了大量开销，例如工具和可访问性问题，而这些问题您原本不需要。

如果没有单页面应用程序，您可以使用诸如 Turbo 和 animate.css 之类的工具，就像 这样。或者，Adam 的新 transition.style，一个基于 clip-path() 的向 Daniel Edan 的杰作致敬。也许如果这种方法与 instant.page 配合使用，它将与任何其他内部链接点击一样快。

还有其他参与者试图解决这个问题，例如 smoothState.js 和 Swup。诀窍是：拦截移动到下一页的操作，先运行动画，然后加载下一页，并对新页面进行动画处理。从技术上讲，这会稍微降低速度，但您可以非常有效地完成它，并且移动会带来足够的干扰，以至于感知到的性能甚至可能更好。

理想情况下，我们不需要对 整个页面 进行动画处理，但我们可以完全控制以创建 更有趣的过渡。哎呀，十年前我就在为一位音乐家制作一个页面，当时 在网站上点击只是移动了一些东西，这样音频就会继续播放（而且很有趣）。

这将是 Web 平台介入的好地方。我记得 Jake 在几年前推动过这件事，但我不确定它是否取得了进展。然后我们得到了 portals，它们还不错？就像您在页面上加载一个 iframe，然后对其进行动画处理使其占据整个页面（并更新 URL）。那里没有太多的动画细微差别，但您当然可以滑动一些页面或淡入淡出（嘿，这里还有另一个： Highway），就像 jQuery Mobile 在古代所做的那样。