Resumo

  • O primeiro rascunho público do W3C, em dezembro de 2012, propôs eventos de ponteiro independentes do equipamento para mouse, toque e caneta, mantendo uma ponte com páginas antigas.
  • A Recomendação de fevereiro de 2015 especificou a família de eventos, pointerType, touch-action para gestos do navegador e captura do ponteiro para arrastos que saem da área do controle.

A campainha do clube tocou, e o porteiro viu um dedo. Na ficha antiga só havia espaço para mouse. Para que a página não ficasse parada, o navegador podia anunciar um evento de mouse mesmo quando quem tocara a tela era uma mão. Era uma fantasia útil, mas não ajudava quem precisava saber se o gesto vinha realmente de um mouse, de uma caneta ou de um toque.

O primeiro rascunho público de Pointer Events do W3C, de 11 de dezembro de 2012, expôs o custo das portas separadas. Sites haviam sido escritos para Mouse Events. Apoiar toque e caneta com outras famílias exigia repetir parte da lógica, enquanto os eventos de mouse por compatibilidade deixavam o instrumento de origem ambíguo. A proposta era um ponteiro: o contato que aponta para uma posição na tela, venha ele de onde vier.

Uma linguagem comum não tira a personalidade dos instrumentos. PointerEvent pode informar pointerType, pressão, tamanho da área tocada e inclinação. Um botão de leitura talvez só precise saber que foi pressionado. Um desenho precisa reconhecer a força da caneta. Primeiro se escreve a ação compartilhada; depois se usa o detalhe que melhora aquela tarefa.

A Recomendação do W3C de 24 de fevereiro de 2015 organizou eventos como pointerdown, pointermove, pointerup e pointercancel, além dos avisos de entrada e saída de uma região. Os nomes lembram a família do mouse, o que facilitava a vida de autores acostumados a ela. A identificação de cada ponteiro ajuda quando mais de um dedo participa da cena.

A ponte com a web anterior também foi descrita. O navegador pode produzir Mouse Events compatíveis a partir de outro tipo de ponteiro para manter páginas antigas utilizáveis. Isso protege um botão que só sabe ouvir o mouse, mas também explica a confusão antiga: o evento chamado «mouse» pode ter nascido de um dedo. Para o código novo, pointerType oferece uma resposta direta.

O conflito mais delicado chega quando o dedo se move. A intenção é arrastar uma peça da página ou deslocar a própria página? Se o navegador precisa esperar o script decidir a cada movimento, a rolagem pode ficar pesada. touch-action declara quais comportamentos táteis normais são permitidos numa região. Assim, o navegador tem informação antecipada para cuidar da rolagem sem pedir licença a cada centímetro.

Há ainda o arrasto que ultrapassa a borda de um controle. Quem move um deslizador pode deixar o dedo escapar do pequeno retângulo sem querer abandonar a operação. A captura do ponteiro mantém os eventos desse contato ligados ao elemento ativo mesmo fora da área. A Recomendação especifica a tomada, a liberação e os sinais gotpointercapture e lostpointercapture. Um dedo não deveria ser punido por fazer uma curva.

O mouse conserva botões e cursor; o dedo traz uma superfície de contato; a caneta pode ter pressão e inclinação. O modelo comum economiza caminhos de código duplicados, enquanto os campos próprios mantêm a precisão onde ela vale. Um aplicativo de desenho não perde a caneta ao aceitar também o mouse.

O histórico de publicação do W3C para Pointer Events 1 registra a estreia pública do rascunho em dezembro de 2012 e a Recomendação em fevereiro de 2015. Nesse intervalo, um problema de autoria virou norma estável: como fazer uma interface criada na era do mouse atender quem toca e desenha diretamente na tela.

O visitante não pede a carteirinha do evento. Quer apertar um botão, rolar sem travar e terminar o arrasto mesmo que o dedo passe da borda. Quando isso acontece, o clube do mouse fica maior sem que ninguém precise vestir um disfarce.