Summary

  • El borrador de Pointer Lock de 2012 permitía a un juego recibir movimiento relativo de ratón sin detenerse en el borde de la pantalla: ocultaba el cursor y enviaba los eventos a un elemento.
  • La Recomendación del W3C de 2016 exigió una acción de desbloqueo siempre disponible; aconsejó Esc para teclados. Tras esa salida elegida por el usuario, la página necesita una nueva interacción antes de recuperar el puntero.

Intenta dar una vuelta completa en un juego en primera persona con un cursor normal. La mano sigue hacia la derecha, pero la flecha tropieza con el monitor y el paisaje se detiene. A quien gira un modelo tridimensional le pasa algo parecido: arrastra hasta que se acaba la mesa digital. El primer borrador público del W3C, de mayo de 2012, planteó una salida vistosa: esconder el cursor del sistema, mandar los eventos del ratón a un elemento elegido y comunicar desplazamientos sin límite de pantalla. El mundo virtual ganó espacio sin que el monitor creciera un centímetro.

No era un arrastre más largo. La captura tradicional termina al soltar el botón. Pointer Lock continúa aunque nadie pulse nada; el cursor deja de necesitar una dirección visible. movementX y movementY cuentan cuánto se ha movido el ratón, mientras las coordenadas de pantalla se mantienen fijas. El personaje consigue cuello; la flechita deja de darse cabezazos contra el borde.

La magia tenía una factura. Si el cursor desaparece y el juego recibe los eventos, cuesta usar los controles del navegador o saltar a otra ventana con el ratón. El apartado de seguridad del borrador de 2012 ya veía el peligro de una página empeñada en recuperarlo cada vez que el usuario escapara. El navegador necesitaba una salida que la propia página no pudiera cerrar. El juego toma prestado el ratón, y el dueño puede reclamarlo.

La Recomendación del W3C de octubre de 2016 fijó las condiciones. Siempre debe existir una acción de desbloqueo predeterminada; Esc es la opción aconsejada cuando hay teclado. También se sale si desaparece el elemento receptor o la pestaña o ventana pierde el foco. pointerlockchange anuncia el cambio y pointerlockerror un intento fallido. Un juego puede devolver el menú común en cuanto termina la captura. El texto recuerda a los programas de aumento de pantalla: durante el bloqueo necesitan una ruta de teclado hasta el punto ampliado.

La cláusula más fina regula el segundo intento. La primera entrada y el regreso después de que la persona use la salida predeterminada requieren una nueva acción de participación para que requestPointerLock() tenga éxito. Si es el propio juego quien llama a exitPointerLock() para abrir un menú, puede volver sin pedir otro gesto. Son salidas distintas: la del jugador rechaza la captura; la del juego cambia de marcha. Si una web pudiera ignorar la primera diferencia, Esc sería una puerta giratoria con un cartel de emergencia.

El borrador Pointer Lock 2.0 de febrero de 2026 recoge unadjustedMovement, una opción para pedir movimiento sin la aceleración del sistema cuando la plataforma lo admite, y una solicitud que devuelve una Promise. En un juego de precisión, un mismo gesto de mano que produce giros distintos por la aceleración no inspira confianza. El texto también ordena la activación breve del usuario y la secuencia de solicitudes de bloqueo y pantalla completa. El historial de publicación 2.0 del W3C va de 2016 a 2026: borrar una flecha exigió mucha letra.

El jugador mira por fin todo el cuarto virtual. Luego quiere abrir otra pestaña o descansar y recupera el ratón. El invento funciona cuando ambas cosas son ciertas: movimiento sin borde para el juego y una salida real para la persona.