Summary

  • Der erste öffentliche Pointer-Lock-Entwurf von 2012 gab Webspielen relative Mausbewegungen ohne Stopp am Bildschirmrand: Der Zeiger verschwindet, ein Element empfängt die Ereignisse.
  • Die W3C-Empfehlung von 2016 verlangt jederzeit eine Möglichkeit zum Entsperren; für Tastaturen wird Esc empfohlen. Nach diesem Ausstieg durch den Menschen braucht die Seite eine neue aktive Geste, bevor sie die Maus erneut sperren darf.

Wer in einem Spiel aus der Ich-Perspektive eine ganze Drehung versucht, trifft mit dem gewöhnlichen Zeiger bald den Bildschirmrand. Die Hand bewegt sich weiter, der Blick bleibt stehen. Bei einem dreidimensionalen Modell endet ein Ziehen ebenso gern mitten in der Drehung. Der erste öffentliche W3C-Entwurf vom Mai 2012 schlug einen geradezu theatralischen Eingriff vor: Systemzeiger verstecken, Mausereignisse an ein ausgewähltes Element schicken und die relative Bewegung ohne Bildschirmgrenze melden. Der Monitor blieb klein; der virtuelle Raum durfte groß sein.

Das war kein verlängertes Ziehen. Herkömmliche Mauserfassung endet, sobald die Taste losgelassen wird. Pointer Lock hält weiter an, auch wenn keine Taste gedrückt ist, und braucht keine sichtbare Adresse für den Zeiger. movementX und movementY liefern die Differenzen; die Bildschirmkoordinaten bleiben stehen. Für den Spieler ist das der Unterschied zwischen einem drehbaren Hals und einem Pfeil, der an der Tapete scheitert.

Die Zauberei hat ihren Preis. Versteckter Zeiger und festes Ereignisziel erschweren den Griff zu Browserknöpfen und anderen Fenstern. Der Sicherheitsabschnitt von 2012 benannte die Gefahr einer Seite, die die Maus nach jedem Ausstieg sofort wieder einsperrt. Der Browser musste deshalb einen Ausweg bereitstellen, den die Seite nicht versperren kann. Ein Spiel darf die Maus ausleihen; sie gehört weiterhin dem Spieler.

Die W3C-Empfehlung vom Oktober 2016 formulierte die Bedingungen. Ein standardmäßiger Entsperrvorgang muss immer verfügbar sein; auf einer Tastatur ist Esc die Empfehlung. Wird das Zielelement entfernt oder verliert Tab oder Fenster den Fokus, endet die Sperre ebenfalls. pointerlockchange meldet den Wechsel, pointerlockerror eine gescheiterte Anfrage. Das Spiel kann sein gewöhnliches Menü zurückbringen. Der Text denkt auch an Bildschirmvergrößerung: Während der Sperre muss der vergrößerte Punkt per Tastatur erreichbar bleiben.

Die feinste Regel betrifft den zweiten Zugriff. Für die erste Sperre und nach einem Ausstieg mit dem Browser-Entsperrvorgang benötigt requestPointerLock() eine neue aktive Zuwendung des Nutzers. Ruft das Spiel dagegen selbst exitPointerLock() auf, um ein Menü zu zeigen, darf es ohne weitere Geste zurückkehren. Zwei Ausgänge, zwei Bedeutungen: Der Mensch widerruft, das Spiel wechselt nur den Modus. Würde beides gleich behandelt, wäre Esc eine Drehtür mit Notausgangsschild.

Der Pointer-Lock-2.0-Entwurf vom Februar 2026 beschreibt unadjustedMovement: Bei unterstützter Plattform kann die Anwendung Bewegung ohne die Beschleunigung des Betriebssystems verlangen. Die Anfrage liefert eine Promise. Für präzises Zielen soll dieselbe Handbewegung nicht je nach Beschleunigung eine andere Kameradrehung ergeben. Der Entwurf behandelt außerdem kurzlebige Nutzeraktivierung und die Reihenfolge von Sperre und Vollbild. Die W3C-Veröffentlichungsgeschichte der Version 2.0 reicht von 2016 bis 2026. Ein verschwundener Pfeil beschäftigte erstaunlich viele Seiten.

Der Spieler kann sich endlich über den alten Bildschirmrand hinaus umsehen. Möchte er eine Pause, kehrt die Maus auf den wirklichen Schreibtisch zurück. Das Kunststück besteht darin, dass beides klappt: grenzenlose Bewegung für das Spiel und ein echter Ausgang für den Menschen.