Summary

  • W3C 2011 年 6 月 2 日的 Page Visibility 工作草案，给页面提供可见状态，并用 visibilitychange 通知状态变化。
  • 草案举了一个邮箱例子：看得见时每隔几秒查一次新信；藏在后台后，可以改成每隔几分钟查一次。节奏由应用自己决定。

邮箱标签页排在地图、文章和一张还没付钱的购物车后面。主人在别处忙着，它却像一位过分敬业的收发员，每隔几秒就打开邮筒看一眼。第一次令人放心，第五十次就该有人告诉它：办公室现在没人。许多页面一起这样忙，处理器和电池也得陪着值班。

W3C 在 2011 年 6 月 2 日发布的 Page Visibility 草案从这个信息差入手。浏览器清楚哪个标签页在前面，窗口有没有最小化，页面是否出现在屏幕上；页面需要一个可以读取、可以监听的信号。草案给出 document.hidden、可见状态和状态变化时的 visibilitychange。浏览器报告自己看到的摆放情况，页面据此安排工作。

作者选的不是实验室里的怪例子，而是网页邮箱。读者盯着收件箱时，每隔几秒向服务器查一次信有其道理；标签页被遮住之后，可以放慢到每隔几分钟一次。邮箱知道自己消息的时效要求，浏览器知道读者眼下能否看到它。两个角色各说自己确实知道的那一半，后台页面就不用按前台的节奏白忙。

更早的2011 年 1 月 W3C 公开邮件列表提案还列过其他场景：拼图游戏被藏起来后暂停计时，周期性轮询可以停一停，视频等到有人打开标签页再播放。同一个可见性信号，不会让三种应用做同一件事。游戏照顾玩家，邮箱节省查询，视频等候观众。标准给它们一条共同的消息，各自决定如何回应。

“藏起来”也需要讲清楚。2011 年草案把后台标签页、最小化的浏览器和锁住的屏幕列为隐藏的例子；页面只要有一部分呈现在某块屏幕上，就算可见。它还顾及屏幕放大等辅助工具：工具覆盖大部分画面时，读者仍可能通过它看着页面。相比只从焦点的进出猜测，这套描述更贴近浏览器对实际显示状态的掌握。

状态会变，所以页面需要事件。visibilitychange让应用在读者切走、切回、再次离开时重新安排任务。只在打开邮箱的第一秒问一次是否可见，管不了之后漫长的一天。2011 年 7 月的 Last Call 草案继续保留这些生活化用例，并整理接口。浏览器每次报状态，网站每次评估自己的作息。

2013 年 5 月的 W3C 推荐标准确定了 hidden、visibilityState 和 visibilitychange，也描述了预渲染、即将卸载等情形下的可选状态。同年 10 月的第二版推荐标准留下一个颇有人情味的脚注：这次修订只改了第 4.3 节里 visibilitychange 事件名称的一处拼写错误。花了几年定义“页面有没有人在看”，最后还得请校对把事件名拼对。标准同样需要编辑。

它与 Web Workers 的边界很清楚。Worker 提供另一个地方去做耗时计算，免得按钮被算式堵住；Page Visibility 告诉应用这份工作此刻值得多频繁地做。邮箱可以同时使用两者：让计算去单独的执行环境，让后台查信慢下来。工作放在哪里，与何时加紧工作，是两个问题。

2011 年草案把处理器和能耗效率写进目标。它的核心却很像生活常识：屋里没人时，收发员不必每隔几秒就跑去开一次门。浏览器知道屋子空了。这个消息传到邮箱页面，后台劳动终于可以有个合适的班次。