O Chrome 47 tem um novo recurso que facilita a compreensão de como os usuários interagem com seu site: InputDeviceCapabilities. Vamos voltar um pouco e aprender por que isso é importante.
Os eventos de entrada do DOM são uma abstração acima dos eventos de entrada de baixo nível, vinculados vagamente
à entrada do dispositivo físico (por exemplo, Os eventos click podem ser disparados por um mouse,
uma tela touchscreen ou um teclado. No entanto, há um problema: não há um método simples
para acessar os detalhes do dispositivo físico responsável por um evento.
Além disso, determinados tipos de entrada podem gerar outros eventos de entrada DOM "falsos" por motivos de compatibilidade. Um desses eventos DOM falsos acontece quando um usuário toca em uma tela sensível ao toque (como em um smartphone). Ele não só dispara eventos de toque, mas também, por motivos de compatibilidade, eventos do mouse.
Isso causa problemas para desenvolvedores ao oferecer suporte a entrada por mouse e por toque. É
difícil saber se um evento mousedown realmente representa uma nova entrada de um mouse ou
é apenas um evento de compatibilidade para um evento touchstart processado anteriormente.
A nova API InputDeviceCapabilities fornece detalhes sobre as fontes de
eventos de entrada usando um objeto sourceCapabilities no UIEvent.
O objeto tem uma propriedade firesTouchEvents definida como true ou false com base em como o evento foi gerado pela ação do usuário.
A pergunta é: onde isso deve ser usado?
Além dos eventos de ponteiro, muitos desenvolvedores atualmente lidam com a lógica de interação na camada de toque, evitando que o padrão evite criar eventos de mouse "falsos". Esse design funciona bem em muitos cenários e não precisa ser mudado para aproveitar o InputDeviceCapabilities.
Mas, em algumas situações, não convém evitar preventDefault o evento de toque.
Por exemplo, ainda convém que os toques enviem eventos de "clique" e mudem o foco. Para
esses casos, as informações contidas na
propriedade MouseEvent.sourceCapabilities.firesTouchEvents permitem começar
a consolidar a lógica de eventos de toque e mouse em um modelo
semelhante à forma como você gerenciaria a lógica com eventos de ponteiro. Ou seja, você pode
ter apenas um conjunto de códigos que gerencia a lógica de interação e oferece aos desenvolvedores uma maneira mais simples
de compartilhar lógica entre navegadores que têm suporte ou não a eventos de ponteiro.
function addMouseEventListener(target, type, handler, capture) {
target.addEventListener(type, function(e) {
if (e.sourceCapabilities.firesTouchEvents)
return false;
return handler(e);
}, capture);
}
A boa notícia é que ele foi Polyfilled (em inglês) por Rick Byers para ser usado na maioria das plataformas.
Atualmente, essa API é mínima e se concentra em resolver um problema específico de identificação de eventos do mouse derivados de eventos de toque.
É possível até mesmo instanciar uma instância do InputDeviceCapabilities.
No entanto, ela contém apenas firesTouchEvents. Futuramente, esperamos uma
expansão
para que você entenda mais sobre todos os dispositivos de entrada no sistema
de um usuário. Gostaríamos de receber seu feedback sobre os
casos de uso.