Chrome 47 には、ユーザーがサイトを操作する方法を簡単に把握できる新しい機能 InputDeviceCapabilities が導入されました。少し立ち止まって、これが重要な理由について説明しましょう。
DOM 入力イベントは、下位レベルの入力イベントの抽象化であり、物理デバイスの入力（click イベントは、マウス、タッチスクリーン、キーボードで発生します）。ただし、イベントの原因となった物理デバイスの詳細を取得する簡単な方法はありません。
また、特定の種類の入力では、互換性上の理由から「偽の」DOM 入力イベントが生成されることがあります。このような偽の DOM イベントの 1 つは、ユーザーがタッチスクリーン（スマートフォンなど）をタップしたときに発生します。このイベントは、タップイベントだけでなく、互換性上の理由からマウスイベントも発生させます。
これにより、マウス入力とタッチ入力の両方をサポートする際にデベロッパーに問題が発生します。mousedown イベントが実際にマウスからの新しい入力を表すのか、以前に処理された touchstart イベントの互換性イベントにすぎないのかを判断するのは困難です。
新しい InputDeviceCapabilities API は、UIEvent の sourceCapabilities オブジェクトを介して、入力イベントの基盤となるソースに関する詳細情報を提供します。
オブジェクトには firesTouchEvents プロパティがあり、ユーザー操作によってイベントが生成された方法に基づいて true または false に設定されます。
問題は、この機能はどこで使用すべきかということです。
多くのデベロッパーは現在、ポインタ イベント以外ではタッチレイヤでインタラクションのロジックを処理しており、デフォルトで「偽の」マウスイベントが最初から作成されないようにしています。この設計は多くのシナリオで適切に機能し、InputDeviceCapabilities を活用するために変更する必要はありません。
ただし、タップによって「クリック」イベントが送信され、フォーカスが変更されるようにしたい場合など、タップイベントの preventDefault を本当に行わないシナリオもあります。このような場合、MouseEvent.sourceCapabilities.firesTouchEvents プロパティに保持されている情報を使用して、タップベースとマウスベースのイベントのロジックを、ポインタ イベントでロジックを管理する場合と同様に類似したモデルに統合できます。つまり、インタラクション ロジックを管理するコードセットを 1 つだけ用意すれば、デベロッパーは、ポインタ イベントをサポートするブラウザとサポートしないブラウザ間でロジックを簡単に共有できます。
function addMouseEventListener(target, type, handler, capture) {
target.addEventListener(type, function(e) {
if (e.sourceCapabilities.firesTouchEvents)
return false;
return handler(e);
}, capture);
}
幸い、Rick Byers によってポリフィルされているため、ほとんどのプラットフォームで使用できます。
現在、この API は最小限に抑えられており、タッチイベントから派生したマウスイベントの特定に関する特定の問題の解決に重点を置いています。InputDeviceCapabilities のインスタンスをインスタンス化することもできますが、firesTouchEvents のみが含まれます。今後、拡張され、ユーザーのシステム上のすべての入力デバイスについて詳しく把握できるようになります。ユースケースに関するフィードバックをお寄せください。