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

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

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

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

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

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

兼顧所有輸入方式

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

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

更多鏈結

原文出處:https://hacks.mozilla.org/2013/04/detecting-touch-its-the-why-not-the-how/

本文上篇:http://blog.mozilla.com.tw/posts/2376/

 

您可能也會喜歡

目前找不到相關文章

對此文章發表回應

你的電子郵件位址並不會被公開。 必要欄位標記為 *