Summary

  • 2012 年 Gamepad 草案让网页游戏直接读取按钮和摇杆。手柄若只能假扮键盘或鼠标，就会丢掉模拟输入的信息，还得借助额外软件。
  • 2025 年 W3C 草案要求先观察到真实的手柄操作，getGamepads() 才向页面交出设备列表。Permissions Policy 另设一道门；摇杆的小抖动不该代替玩家敲门。

玩家接上手柄，打开游戏。键盘能告诉页面某个键按下了，却说不清扳机究竟压到几成，也讲不出摇杆偏向左上方多少。鼠标指针要替方向盘说话，就更吃力。2012 年 5 月 W3C 第一份公开草案 想省掉这种拙劣翻译。它把按钮、轴、设备标识、索引和状态更新时间交给脚本，还定义连接与断开的事件。游戏终于能让手柄做手柄，不必逼它穿上办公室键盘的制服。

早期接口很朴素。一根轴在 -1 到 1 之间移动，按钮值在 0 到 1 之间变化；半压下的扳机仍是半压下，而非一声生硬的“开”。设备 id 帮应用知道遇见哪一类手柄，索引帮助几位玩家坐在沙发上时分清是谁暂停了游戏。这些信息有用，也像一张小小的设备登记表。如果网页在游戏开始前就能读出它，路过的页面也能知道访客桌边摆着什么。

于是手柄自己成了最合适的介绍人。2025 年 7 月 10 日的 W3C 草案 写明：在观察到用户的手柄操作之前，navigator.getGamepads() 返回空列表。草案直接指出这是为了减轻设备指纹风险。硬件可能早已连接，但网页此时拿不到名单。玩家真按下按钮，或有意拨动能自动回中的摇杆，浏览器才把设备展示给脚本。介绍从人的动作开始，不从网站的好奇心开始。

这条规则听着像一只门铃，写起来却像修弹簧。有的开关按下后会一直保持，有的摇杆在中点附近轻微漂移。卡住的开关和偶然噪声都不该算作新的问候。2025 年草案因此要求浏览器识别从中立状态出发的动作：曾经松开的按钮变为按下，或曾经靠近中点的轴越过一定阈值。坏弹簧没有资格替玩家向全城网页打招呼。

门也不止一道。2025 年草案还要求未处于活动状态的文档拿到空列表；若文档没有 gamepad 这项 Permissions Policy 权利，调用会得到 SecurityError。玩家的动作是设备向脚本显现的条件，不是一场把所有权限送给所有嵌入页面的仪式。浏览器管页面能不能用，应用管按键代表什么，玩家负责第一次实际操作。三个决定最好别搅成一锅。

手柄显现后，游戏仍要持续拿到及时的状态快照。getGamepads() 以数组返回已连接且发生过交互的手柄，空掉的索引留下 null；连接事件则告诉应用谁来了、谁走了。索引是记账位置，拔掉设备后可重新分配，并非永恒身份证。按钮和轴承载的才是眼前动作：跳跃、转弯、刹车，或坐在沙发上操控客厅屏幕。接口交出动作，不替游戏编剧情。

W3C 发布年表 从 2012 年第一份草案延伸到 2025 年版本。日期记录文本，不保证所有浏览器同日采用同样行为。设计演进的方向已经很清楚：网页游戏需要真实的手柄输入；普通网页没必要趁玩家还没拿起手柄，就给他的设备点名。

玩家终于按下按钮，游戏角色动了。网页拿到介绍，时机刚好：握着设备的人先按了门铃。