سيتوفر auxclick قريبًا في الإصدار 55 من Chrome

Jeff Posnick

متى لا تكون النقرة click؟ بالنسبة إلى مطوّر الويب الذي يعمل على واجهة مستخدم معقدة، هذا ليس سؤالاً فلسفيًا مجردًا. إذا كنت بصدد تنفيذ سلوك مخصّص لإدخال الماوس، من المهم مراعاة نية المستخدم. على سبيل المثال، إذا نقر أحد المستخدِمين على رابط باستخدام الزر الأوسط في الماوس، من المنطقي افتراض أنّه أراد فتح علامة تبويب جديدة تتضمّن محتوًى من ذلك الرابط. إذا نقر المستخدم بالوسط على عنصر عشوائي في واجهة المستخدم، قد تريد افتراض أنّه كان غير مقصود وتجاهل هذا الإدخال، في حين أنّه من المتوقّع أن يؤدي استخدام زر أساسي للنقر إلى تحفيز استجابة من واجهة المستخدم.

من الممكن، وإن كان ذلك صعبًا بعض الشيء، وضع نماذج لهذه التفاعلات الدقيقة من خلال معالج حدث واحد من نوع click. عليك التحقّق صراحةً من سمة button MouseEvent، لمعرفة ما إذا تم ضبطها على 0، التي تمثّل الزر الأساسي، أو أي شيء آخر، مع 1 التي تمثّل عادةً الزر الأوسط، وما إلى ذلك. ولكن لا يتحقق الكثير من المطوّرين صراحةً من سمة button، ما يؤدي إلى إنشاء رمز يعالج جميع click بشكلٍ متطابق، بغض النظر عن الزر الذي تم الضغط عليه.

بدءًا من الإصدار 55 من Chrome، يتم تنشيط نوع جديد من MouseEvent يُسمى auxclick استجابةً لأي نقرات يتم إجراؤها باستخدام زر غير أساسي. يصاحب هذا الحدث الجديد تغييرًا ملائمًا في سلوك الحدث click: لن يتم تفعيله إلا عند الضغط على زر الماوس الأساسي. نأمل أن تسهّل هذه التغييرات على مطوّري الويب كتابة معالِجات الأحداث التي تستجيب فقط لنوع النقرات التي تهمّهم، بدون الحاجة إلى التحقّق تحديدًا من السمة MouseEvent.button.

تقليل النتائج الموجبة الخاطئة

كما ذكرنا، كان أحد الدوافع لإنشاء auxclick هو تجنُّب نشرمعالجي 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 لن يتم تنفيذ وظائف الاستدعاء إلا عند النقر على زر فأرة غير أساسي. إذا كان لديك رمز برمجي يحتاج مثلاً إلى احتساب عنوان URL مناسب للوجهة قبل فتح علامة تبويب جديدة، يمكنك الاستماع إلى الحدث auxclick وتضمين هذا المنطق في رمز الاستدعاء. ولن يتسبب ذلك في زيادة تكلفة التشغيل عند النقر على زر الماوس الأساسي.

توافق المتصفّح ومدى توافقه

لا يتم تنفيذ هذا السلوك الجديد حاليًا إلا في الإصدار 55 من Chrome. كما هو موضّح في الاقتراح الأوّلي، نُقدّر بشدة ملاحظات مطوّري الويب (سواء كانت إيجابية أو سلبية). إنّ الإبلاغ عن مشكلة على GitHub هو أفضل طريقة لمشاركة هذه الملاحظات مع الفريق الذي يعمل على عملية التوحيد.

في الوقت الحالي، لا يحتاج المطوّرون إلى انتظار توفّر auxclick على نطاق واسع لاتّباع بعض أفضل الممارسات في التعامل مع أحداث الماوس. إذا أخذت الوقت للتحقّق من قيمة السمة MouseEvent.button في بداية معالج الحدث click، يمكنك التأكّد من اتّخاذ الإجراء المناسب. سيعالج النموذج التالي النقرات الأساسية والمساعدة بشكلٍ مختلف، سواء كان هناك توافق أصلي مع 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);