偵測觸碰事件：重點在「原因」而非「方法」─ 下篇

作者：news

2013-04-22 14:22:45

323322

要用手指碰還是用滑鼠點？

那這種同時具備觸控與其他輸入方式的裝置，又有什麼解決方案呢？透過某些使用者的意見，已經有開發人員著手建構「觸碰」的偵測功能。如同其他許多網頁開發的案例，我們當然不可能完全了解使用者對網頁與 App 的互動方式，也不會知道使用者的輸入偏好。與其假設一大堆東西，到不如讓程式碼儘量滿足所有可能性。進一步來說，與其決定要以 click 或 touchend/touchstart 互動，乾脆就全部納入建構考量。

當然，程式碼可能會長一點多一點，卻能讓 App 吸引更多使用者。若開發人員已經讓特定滑鼠的介面也能搭配鍵盤，那他們應該會覺得這個方法很熟悉：只要「交疊 (Double up)」事件接收器 (Listener) 即可。但同時應停止模擬的滑鼠事件，以避免在觸碰事件之後啟動，而造成雙重發動的狀態：

blah.addEventListener('touchend', function(e) { /* prevent delay and simulated mouse events */ e.preventDefault(); someFunction() }); blah.addEventListener('click', someFunction());

如果你覺得這樣還不夠 DRY 的話，這裡還可以讓程式更漂亮。但僅能針對滑鼠點擊的動作而定義函式，接著再確實發動處理器 (Handler)，進而繞過延遲不管：

blah.addEventListener('touchend', function(e) { /* prevent delay and simulated mouse events */ e.preventDefault(); /* trigger the actual behavior we bound to the 'click' event */ e.target.click(); }) blah.addEventListener('click', function() { /* actual functionality */ });

最後的片段並不足以囊括所有可能的情況。若需要更完整的範例，可參閱 FT labs 所提供的 FastClick 指令碼。

兼顧所有輸入方式

觸控式裝置上的延遲功能，並不是開發人員與觸控功能奮戰的唯一理由。目前的相關討論 (如 Modernizr 中的 detecting a mouse user 一文) 已經談到是否該針對觸控功能，而提供與滑鼠/鍵盤截然不同的介面；其中也提到如懸浮觸控的特定裝置或瀏覽器。且除了 JavaScript 之外，類似的概念 (指示器與懸浮媒體功能) 也擴及到 Media Queries Level 4。但相關原理幾乎都一樣：現在多重輸入的裝置已經普及，使用者手上的裝置也幾乎不可能只支援觸控功能。

只要 Microsoft 讓 Pointer Events 採用更多通用規格 ─ 其實已經著手建構如 Chrome 的瀏覽器 ─ 就代表他們朝著正確的方向前進 (但仍須另外滿足鍵盤愛好者的需求)。在此同時，開發人員應小心翼翼，避免錯估了觸控偵測功能的形勢，也避免忽略了愛好多重輸入的潛在人數。