Summary

  • O primeiro rascunho público de Pointer Lock, em 2012, permitiu ler o movimento relativo do mouse sem parar na borda da tela: o cursor some e um elemento recebe os eventos.
  • A Recomendação W3C de 2016 exige uma ação de saída sempre disponível; Esc é recomendado no teclado. Depois que a pessoa sai por esse caminho, a página precisa de novo engajamento para capturar o mouse outra vez.

Experimente girar a câmera de um jogo em primeira pessoa com o cursor comum. A mão continua indo para a direita, mas a seta encontra a moldura da tela e o mundo para. Um artista girando um modelo tridimensional esbarra no mesmo limite durante o arrasto. O primeiro rascunho público do W3C, de maio de 2012, propôs um truque vistoso: esconder o cursor do sistema, enviar os eventos para um elemento escolhido e informar quanto o mouse andou, sem teto imposto pela tela. O monitor ficou do mesmo tamanho; o mundo do jogo, não.

Isso ia além de alongar um arrasto. A captura tradicional solta o alvo quando o botão é liberado. Pointer Lock continua sem botão pressionado e dispensa o endereço visível do ponteiro. movementX e movementY carregam os deslocamentos; as coordenadas na tela ficam paradas. A personagem ganha um pescoço que gira, em vez de uma flecha batendo a cabeça na parede do monitor.

O truque tem cobrança. Se o cursor some e o jogo recebe todos os eventos, fica difícil clicar nos controles do navegador ou em outra janela. A seção de segurança do rascunho de 2012 já apontava o abuso possível: uma página poderia prender o mouse de novo cada vez que alguém escapasse. O navegador precisava guardar uma saída que a página não controlasse. O jogo pega o mouse emprestado; a pessoa pode pedi-lo de volta.

A Recomendação do W3C de outubro de 2016 deu forma a esse acordo. Uma ação padrão de desbloqueio deve estar sempre disponível; para teclados, recomenda-se Esc. Se o elemento alvo desaparece ou a aba ou janela perde o foco, o bloqueio também termina. pointerlockchange avisa que o estado mudou; pointerlockerror indica falha. O jogo pode então mostrar um menu normal. O texto ainda lembra os programas de ampliação da tela: com o ponteiro preso, eles precisam de um caminho pelo teclado até o ponto ampliado.

A regra mais esperta diz respeito à segunda captura. Na primeira entrada e depois que a pessoa usa a saída padrão do navegador, requestPointerLock() exige uma nova ação de engajamento. Se o próprio aplicativo chama exitPointerLock() para exibir um menu, pode voltar sem pedir outro gesto. As saídas expressam decisões diferentes. A da pessoa é um veto; a do jogo é troca de marcha. Se a página ignorasse essa diferença, Esc viraria uma porta giratória com placa de saída.

O rascunho Pointer Lock 2.0 de fevereiro de 2026 descreve a opção unadjustedMovement, que pede movimento sem a aceleração do sistema onde houver suporte, e uma solicitação que retorna Promise. Para uma mira precisa, a mesma mexida da mão deve produzir um giro previsível. O texto também detalha a ativação breve do usuário e a ordem das solicitações de bloqueio e tela cheia. O histórico W3C da versão 2.0 vai de 2016 a 2026. Uma seta que desaparece pode exigir anos de conversas.

A pessoa gira além da antiga borda e vê a sala virtual inteira. Depois quer uma pausa e recupera o mouse. O êxito está nas duas ações: o jogo ganha movimento sem parede; quem joga mantém a porta de saída.