摘要

  • W3C 2012 年 7 月 3 日的 Fullscreen 工作草案允许网页元素申请全屏、文档退出全屏，也规定了顶层显示和由用户发起的退出。
  • W3C 2014 年停止维护这份文件并指向 WHATWG。现行标准为通常的全屏申请设置短暂用户激活条件，限制嵌入内容，并要求浏览器提供始终有效的出口。

设想一家由网页经营的电影院。视频播放器要暗场，游戏要整面墙，幻灯片还嫌地址栏抢戏。经理都可以点头。等有人问“散场从哪里走”，放映技术立刻变成权力分配：网页负责节目，谁负责打开门？

W3C 于 2012 年 7 月 3 日发布的首份公开工作草案给出了几个直接的动作。元素调用 requestFullscreen()，文档可以调用 exitFullscreen()，fullscreenElement 告诉程序眼下是谁占着屏幕。这份草案里的方法返回 void。它是工作草案，不是后来颁布的一份正式推荐标准；发布日期也不能冒充某款浏览器首次上线的日期。

草案关心的并非只把矩形放大。全屏元素进入文档的全屏栈，也进入绘制顺序中最靠近观众的顶层。普通网页早就能用 CSS 画一块巨大色板；全屏却动到了浏览器视口和用户界面。一个自信过头的 div 可以占很大地方，却不能凭气势宣布整台显示器归自己管。

申请还有门槛。2012 年的算法会检查元素是否仍在文档中、上下文是否允许全屏、嵌套状态是否冲突，以及草案当时使用的弹窗许可条件。既有用户偏好、安全风险和平台限制也能让申请失败。这里没有神秘的“网页主权”：页面递交申请，浏览器握着审批章。

退出一开始就在合同里。草案要求，用户指示浏览器结束通过该接口开启的全屏时，浏览器应完整退出。它还容许显示如何离开的提示。fullscreenchange 让网页得知状态变化，哪怕按下退场按钮的并非网页脚本。播放器可以据此暂停或重排控件；它不能把已经拿到的屏幕当成永久租约。

档案里有一个容易讲错的转折。W3C 2014 年 11 月 18 日的工作组说明明确说，该文件的工作已经停止，并让实现者转看 WHATWG 的 Fullscreen 规范。停止的是 W3C 那份文件的推进，不是全屏功能本身。2012 年草案也没有在 2014 年神奇升级成 W3C 推荐标准。标准的写作场所换了，网页和浏览器之间的门禁问题还在。

WHATWG 现行 Fullscreen 活标准把交易写得更细。如今 requestFullscreen() 与 exitFullscreen() 返回 Promise。通常情况下，申请需要短暂的用户激活，例如刚发生的互动；标准还列出了由用户造成的屏幕方向变化这一特定情形。浏览器接受请求时会消耗这次激活。用户点视频和网页悄悄载入后自封影厅，在规则里有不同待遇。

现行规范仍有顶层。带全屏标志且在顶层最靠上的元素，才是文档当前的全屏元素。:fullscreen 和背景绘制让页面能安排画面，fullscreenchange 与 fullscreenerror 则让程序分别听见成功和拒绝。别把今天的 Promise 与权限策略塞回 2012 年原稿：这两份文档之间隔着一次真实的标准演进。

嵌入页面最能说明为什么要守门。假设你在某站打开一段由第三方 iframe 提供的视频。谁有资格突然占满你的屏幕？现行标准将 fullscreen 设为受权限策略控制的功能，默认许可名单是 'self'；嵌入内容需要通过 iframe 的 allowfullscreen、allow 或相应策略头明确获准。剧院可以请外来的剧团演出，舞台钥匙仍由剧院管理。

最后是那块小小的出口灯。现行标准要求浏览器让用户知道自己正在看全屏，并提供始终可用、能让用户找到的退出方式。原因非常具体：全屏网页可以画出假的浏览器，甚至假的操作系统界面。浏览器必要时还可以主动结束会话。全屏因此既是沉浸工具，也是防止舞台伪装成大楼的门禁设计。

这段历史值得写，不是因为网页终于会把视频放大，而是因为开放平台给了应用强大的展示能力，同时没有把读者锁在应用里。电影可以占满视野。门口那盏绿色小灯，仍由观众和浏览器说了算。