您和使用者都希望行動網路應用程式 能流暢地 輕觸。開發行動應用程式應該容易，但不幸的是，行動版網站的開發方式 瀏覽器在捲動期間對觸控事件做出回應，繼續實作 TouchEvent 規格的詳細介紹。阿斯 因此，方法可大致分成 4 類。這個 從環境到可順暢捲動 降低開發人員的控制權
處理觸控事件的四種不同模型
瀏覽器之間的行為差異可分為四個模型。
一般的同步事件處理
系統會在捲動期間傳送觸控移動事件，並每次捲動更新區塊，直到觸控移動程序完成為止。這種做法的好處是最簡單明瞭，而且功能最強大，但對捲動效能而言不佳，因為這表示捲動期間的每個影格都必須封鎖主執行緒。
瀏覽器：Android 瀏覽器 (Android 4.0.4、4.3)、行動版 Safari (捲動 div 時)
非同步觸控移動處理
觸控移動事件會在捲動期間傳送，但可以透過非同步方式繼續捲動 (開始捲動後，系統會忽略觸控移動事件)。這可能會導致「重複處理」事件 (例如當網站發生觸控移動時繼續捲動)，並在事件中呼叫 preventDefault，指示瀏覽器不要處理這個事件。
瀏覽器：行動版 Safari (捲動文件時)、Firefox
捲動時無法觸控移動
捲動開始後，系統不會傳送觸控移動事件，必須等到觸控事件結束後才會繼續。在此模型中，使用者難以分辨固定觸控與捲動的差異。
瀏覽器：Samsung 瀏覽器 (已傳送 Mousemove 事件)
捲動啟動時的觸控取消
無法同時採用這兩種做法 (例如捲動流暢度和開發人員控制項)，而且這個模型與指標事件規格的語意類似，會明確區分流暢捲動和事件處理之間的取捨。但有些功能需要追蹤手指，例如拉動重新整理。
瀏覽器：Chrome 電腦版 M32 以上版本、Chrome Android
為什麼要變更？
Chrome for Android 目前使用 Chrome 的舊模型：捲動時可觸控取消 來提升捲動效能，但會導致開發人員混淆。 特別是部分開發人員並不知道觸控取消事件，或如何 因而導致部分網站無法正常運作更重要的是 整個 UI 捲動效果和行為類別，例如「提取即可重新整理」。 隱藏式長條和分子點很難或無法執行
比起新增特別硬式編碼功能來支援這些效果， Chrome 的目標是將重心放在新增方便開發人員使用的平台基本功能 以便直接實作這些效果請參閱 A Rational Web Platform 一般說明這個理念
Chrome 的新模型：節流的非同步觸控移動模型
Chrome 將推出新行為
來提升與為其他瀏覽器編寫程式碼的相容性
以及啟用其他需要觸控移動的情境
事件。這項功能預設為啟用，您可以自行決定是否要開啟
並加上下列標記 chrome://flags\#touch-scrolling-mode。
新行為如下：
- 第一個觸控移動會同步同步傳送， 已取消
- 主動捲動期間
- 觸控移動事件會非同步傳送
- 限制為每 200 毫秒 1 個事件，或 CSS 15px 滑動區域 超過
- Event.cancelable 為 false
- 否則，在主動捲動時，觸控移動事件會照常觸發 終止或無法執行該動作
- 使用者舉起手指時，「一律」會發生觸控事件
您可以在 Chrome for Android 中試用這個示範，並將
chrome://flags\#touch-scrolling-mode 標記來查看差異。
請提供您寶貴的意見
非同步觸控移動模型可望改善跨瀏覽器體驗 ，並啟用全新的觸控手勢效果。我們想 聆聽開發人員的想法，以及看到創意十足的作品 。