摘要

  • W3C 于 2020 年 2 月 11 日发布第一版公开草案：浏览器在可见区域附近选择锚点，上方内容改变布局时，以滚动位移补偿锚点的移动。
  • 同年 11 月 11 日的草案进一步说明候选锚点以及它与滚动捕捉的关系。页面可用 overflow-anchor: none 排除特定区域。

那一段刚读出味道，广告来了。它从文章上方插队，整页往下挤，读者只好重新寻找刚才的句子。浏览器看上去挺守规矩：滚动条仍停在原来的数值。问题恰恰出在这份规矩上。网页在视野外长高了，原来的滚动距离便无法代表原来的阅读位置。数字没跑，段落跑了。

W3C 于 2020 年 2 月 11 日发布的第一版公开草案直接点出两种常见闯入者：脚本后来插入广告 iframe，以及没有预留尺寸、在慢网络上才加载完的图片。它们都能让屏幕上方突然增加高度。网站预先留好空间，读者自然省心；草案又给浏览器一层补救能力，处理那些已经发生的意外。

补救先要回答：该固定谁？浏览器在滚动容器内部寻找一个锚点节点，倾向于文档树中较深、又靠近可见区域起始边缘的元素。它记录锚点原来的位置，再看布局变化后锚点到了哪里。两者相差多少，就准备相应地调整滚动位置。广告占了位置，读者正在看的那行仍留在眼前。这不是把广告藏起来，而是把新增高度从读者的阅读坐标里扣回去。

选锚点也有讲究。页面里有导航、图片、装饰、正在变化的组件；随便抓一个元素当参照，会把稳定变成另一种跳动。草案规定候选资格，并设有“抑制窗口”，让等待中的调整在布局处理的合适阶段落实。它处理的是一段时间内的页面变化，而不是每次有个盒子挪动就忙乱地追着跑。

2020 年 11 月 11 日的工作草案把“可用候选”和“优先候选”写得更清楚，也澄清了与滚动捕捉的配合：有些页面本来就设计了明确的停靠位置。W3C 的发布历史列出当年的两次公开版本；其2 月公告把目的讲得很朴素：别让可见区域外的变化把正在读的页面掀动。

网页作者仍握着一只方向盘。overflow-anchor 的初始值是 auto；设为 none，可以让整个滚动区域不参与锚定，也可以从候选范围中剔除一部分子树。自己控制滚动位置的组件，或者刻意安排移动效果的区域，便能标明边界。默认规则照顾多数阅读场景，局部选择留给具体页面。

这项设计最妙的地方，是把“原地”重新定义了一遍。原地曾是滚动条上的一个数。现在它可以是读者盯着的那一行。广告爱迟到就迟到吧；那句话已经有了自己的座位。