Summary

  • El borrador de Gamepad de 2012 ofreció a los juegos los valores de botones y ejes. Hacer pasar un mando por ratón o teclado perdía información analógica y exigía programas adicionales.
  • El borrador W3C de 2025 mantiene vacía la lista de mandos hasta detectar un gesto auténtico del jugador. La Permissions Policy es otro control; una palanca que tiembla sola no debe llamar al timbre.

El jugador conecta el mando. Una tecla puede decir «estoy pulsada», pero no cuánto se ha apretado un gatillo. Un ratón es peor traductor de un volante ligeramente girado. El primer borrador público del W3C, de mayo de 2012, quería librarse de esa pantomima. Daba al script ejes, botones, una identificación, un índice y una marca del momento en que cambió el estado. También avisaba cuando el aparato se conectaba o desaparecía. El mando podía dejar de disfrazarse de herramienta de oficina.

La escala era útil precisamente por sencilla. Un eje iba de -1 a 1; un botón, de 0 a 1. Un gatillo apretado a medias conservaba su mitad. El id orientaba a la aplicación sobre el tipo de mando; el índice distinguía a varias personas sentadas ante una pantalla. Si alguien pausa la partida en el sofá, conviene saber quién fue. Sin embargo, esa misma lista cuenta qué equipo tiene el visitante. Una página capaz de leerla antes de que empiece el juego obtiene un pequeño inventario aunque nadie haya querido jugar.

La presentación puede hacerla el propio jugador. El borrador del W3C del 10 de julio de 2025 dispone que navigator.getGamepads() devuelva una lista vacía hasta observar un gesto con un mando. El texto menciona la reducción del fingerprinting. Puede haber hardware enchufado; la página aún no recibe sus datos. Un botón pulsado o una palanca centrada que alguien mueve con intención inicia la conversación. La mano llega antes que la curiosidad del sitio.

Una regla de timbre necesita saber si ha sonado de verdad. Algunos interruptores permanecen activados; algunas palancas vibran mínimamente alrededor del centro. Eso no es una invitación nueva. Por ello el borrador exige reconocer una transición desde el estado neutro: un botón visto antes sin pulsar pasa a estar pulsado, o un eje que descansaba cerca del centro supera un umbral. Un muelle viejo no puede presentar por su cuenta al propietario ante media internet.

Hay más puertas. Un documento que no está plenamente activo recibe una lista vacía. Si la Permissions Policy gamepad no lo autoriza, getGamepads() produce SecurityError. El gesto del jugador condiciona cuándo aparece el dispositivo ante el script; no entrega todos los permisos a cualquier contenido incrustado. El navegador decide qué documento puede usar la función, la aplicación decide qué significa cada botón y la persona decide cuándo comienza la interacción. Conviene no mezclar esas tres decisiones.

Tras la presentación, el juego consulta estados recientes. El arreglo de getGamepads() muestra los mandos conectados con los que hubo interacción y deja null en los índices vacantes. Los eventos comunican conexiones y desconexiones; un índice puede reutilizarse tras retirar un mando, porque es contabilidad y no identidad eterna. Lo que importa en la partida son los valores de los ejes y botones: saltar, girar, frenar o manejar una interfaz desde el sofá. La API lleva el movimiento; el guion lo escribe el juego.

El historial de publicaciones del W3C arranca en 2012 y llega al texto de 2025. Son fechas de documentos, no un calendario de adopción idéntica en todos los navegadores. El problema que resolvían es fácil de ver: los juegos necesitaban leer mandos con fidelidad, y las páginas ociosas no necesitaban pasar lista a los aparatos antes de que alguien los tocara.

El jugador aprieta por fin un botón. El personaje se mueve. El navegador abrió después de que la persona con el mando llamara al timbre.