什麼時候點擊不是 click？對於負責複雜使用者介面的網頁開發人員而言，這並非抽象的哲學問題。如果您要實作自訂滑鼠輸入行為，請務必考量使用者意圖。舉例來說，如果使用者按下滑鼠中鍵開啟連結，我們可以合理推測使用者想開啟新分頁，並在其中顯示該連結的內容。如果使用者按下隨機的 UI 元素，您可能會假設這是不小心按下，並忽略該輸入內容，而主要按鈕的點擊動作則會觸發 UI 的回應。
您可以透過單一 click 事件監聽器模擬這些細微的互動，但這麼做可能會比較麻煩。您必須明確檢查 MouseEvent 的 button 屬性，瞭解該屬性是否已設為 0 (代表主要按鈕)，而非其他屬性 (1 通常代表中間按鈕) 等。但很少開發人員會明確檢查 button 屬性，因此無論按下哪個按鈕，程式碼都會以相同方式處理所有 click。
自 Chrome 55 版起，系統會在回應使用非主要按鈕的任何點擊時，觸發名為 auxclick 的新類型 MouseEvent。這項新事件會伴隨 click 事件的行為變更：只有在按下滑鼠主按鈕時才會觸發。我們希望這些變更可讓網頁開發人員更輕鬆地撰寫事件處理常式，只回應他們關心的點擊類型，而無需特別檢查 MouseEvent.button 屬性。
減少誤報
如前所述，建立 auxclick 的原因之一，是為了避免部署自訂 click 處理常式，誤將「中鍵點選開啟分頁」行為覆寫。舉例來說，假設您已編寫 click 事件處理常式，該常式會使用 History API 重新撰寫位置列，並實作自訂單頁導覽。可能如下所示：
document.querySelector('#my-link').addEventListener('click', event => {
event.preventDefault();
// ...call history.pushState(), use client-side rendering, etc....
});
當自訂邏輯由滑鼠的主要按鈕觸發時，可能會正常運作，但如果在按下中間按鈕時執行該程式碼，實際上會是誤判。在新的行為推出之前，您會禁止開啟新分頁的預設動作，這與使用者的期望背道而行。雖然您可以在處理常式開始時明確檢查 event.button === 0，並只在該情況下執行程式碼，但很容易忘記，或從未意識到需要這樣做。
只執行所需程式碼
減少誤判的另一個好處是，只有在實際按下非主要滑鼠按鈕時，才會執行 auxclick 回呼。如果程式碼需要在開啟新分頁前計算適當的目標網址，您可以監聽 auxclick，並在回呼中加入該邏輯。這樣一來，當使用者按下滑鼠主按鈕時，就不會產生執行的額外負擔。
瀏覽器支援和相容性
這項新行為目前僅在 Chrome 55 中實作。如最初的提案所述，我們非常歡迎網路開發人員社群提供意見回饋 (無論是正面還是負面)。如要與負責標準化程序的人員分享意見回饋，最好的方法就是提交 GitHub 問題。
在此同時，開發人員不必等到 auxclick 全面開放，就能遵循一些處理滑鼠事件的最佳做法。如果您在 click 事件處理常式的開頭花時間檢查 MouseEvent.button 屬性的值，就能確保採取適當的動作。無論是否支援 auxclick 的原生功能，以下模式都會以不同的方式處理主要和輔助點擊：
function handlePrimaryClick(event) {
// ...code to handle the primary button click...
}
function handleAuxClick(event) {
// ...code to handle the auxiliary button click….
}
document.querySelector('#my-link').addEventListener('click', event => {
if (event.button === 0) {
return handlePrimaryClick(event);
}
// This provides fallback behavior in browsers without auxclick.
return handleAuxClick(event);
});
// Explicitly listen for auxclick in browsers that support it.
document.querySelector('#my-link').addEventListener('auxclick', handleAuxClick);