تبدو تلميحات الأدوات وكأنها أصغر مشكلة في واجهة المستخدم يمكن أن تواجهك. إنها صغيرة وعادة ما تكون مخفية. عندما يسأل شخص ما عن كيفية إنشاء واحدة، فإن الإجابة التقليدية تأتي دائمًا تقريبًا باستخدام بعض مكتبات JavaScript. ولفترة طويلة، كانت هذه هي النصيحة المعقولة. لقد تابعته أيضًا. على السطح، تلميح الأداة بسيط. قم بالتمرير أو التركيز على عنصر ما، وإظهار مربع صغير يحتوي على بعض النص، ثم قم بإخفائه عندما يتحرك المستخدم بعيدًا. ولكن بمجرد شحن واحدة إلى مستخدمين حقيقيين، تبدأ الحواف في الظهور. يقوم مستخدمو لوحة المفاتيح بالضغط على المشغل، لكنهم لا يرون تلميح الأداة مطلقًا. تعلن قارئات الشاشة عن ذلك مرتين، أو لا تعلنه على الإطلاق. يومض تلميح الأداة عند تحريك الماوس بسرعة كبيرة. يتداخل مع المحتوى على الشاشات الصغيرة. الضغط على Esc لا يغلقه. يضيع التركيز. بمرور الوقت، تطور رمز تلميح الأدوات الخاص بي إلى شيء لم أعد أرغب في امتلاكه بعد الآن. تراكمت مستمعي الحدث. كان لا بد من التعامل مع التمرير والتركيز بشكل منفصل. تحتاج النقرات الخارجية إلى حالات خاصة. يجب أن تظل سمات ARIA متزامنة يدويًا. أضاف كل إصلاح صغير طبقة أخرى من المنطق. ساعدت المكتبات، لكنها كانت أيضًا أشبه بالصناديق السوداء التي عملت حولها بدلاً من أن أفهم تمامًا ما كان يحدث خلف الكواليس. كان هذا ما دفعني إلى إلقاء نظرة على واجهة Popover API الأحدث. أردت أن أرى ما سيحدث إذا قمت بإعادة إنشاء تلميح أداة واحد باستخدام النموذج الأصلي للمتصفح دون مساعدة المكتبة. عندما نبدأ، تجدر الإشارة إلى أنه، كما هو الحال مع أي ميزة جديدة، هناك بعض الأشياء التي لا تزال قيد التسوية. ومع ذلك، فهو يتمتع حاليًا بدعم رائع للمتصفح، على الرغم من وجود عدة أجزاء من واجهة برمجة التطبيقات الشاملة التي هي في حالة تغير مستمر. من الجدير مراقبة Caniuse في هذه الأثناء. تلميح الأدوات "القديم". قبل Popover API، لم يكن استخدام مكتبة تلميحات الأدوات بمثابة اختصار. لقد كان الافتراضي. لم يكن لدى المتصفحات مفهوم أصلي لتلميح الأدوات الذي يعمل عبر الماوس ولوحة المفاتيح والتكنولوجيا المساعدة. إذا كنت تهتم بالصحة، كان خيارك الوحيد هو استخدام المكتبة، وهذا بالضبط ما فعلته. على مستوى عالٍ، كان النمط دائمًا هو نفسه: عنصر تشغيل، وعنصر تلميح أداة مخفي، وجافا سكريبت للتنسيق بين الاثنين.
تعاملت المكتبة مع الأسلاك التي سمحت للعنصر بالظهور عند التمرير أو التركيز، والإخفاء عند التمويه أو ترك الماوس، وتغيير الموضع/تغيير الحجم عند التمرير.
بمرور الوقت، قد يصبح تلميح الأداة هشًا. التغييرات الصغيرة تحمل المخاطر. تسببت الإصلاحات الطفيفة في التراجعات. والأسوأ من ذلك أن إضافة تلميحات أدوات جديدة ورثت نفس التعقيد. سارت الأمور من الناحية الفنية، ولكن لم أشعر أبدًا بالاستقرار أو الاكتمال. كان هذا هو الوضع عندما قررت إعادة بناء تلميح الأداة باستخدام Popover API الأصلي للمتصفح. اللحظة التي جربت فيها Popover API لم أتحول إلى استخدام Popover API لأنني أردت تجربة شيء جديد. لقد قمت بالتبديل لأنني سئمت من الحفاظ على سلوك تلميحات الأدوات الذي أعتقد أن المتصفح يجب أن يفهمه بالفعل. كنت متشككا في البداية. تعد معظم واجهات برمجة تطبيقات الويب الجديدة بالبساطة، ولكنها لا تزال تتطلب الغراء أو معالجة حالة الحافة أو المنطق الاحتياطي الذي يعيد بهدوء نفس التعقيد الذي كنت تحاول الهروب منه. لذا، قمت بتجربة Popover API بأصغر طريقة ممكنة. إليك ما بدا عليه الأمر:
1. لوحة المفاتيح "تعمل فقط" يعتمد دعم لوحة المفاتيح على طبقات متعددة تصطف بشكل صحيح: يجب أن يؤدي التركيز إلى تشغيل تلميح الأداة، ويجب أن يخفيه التمويه، ويجب توصيل Esc يدويًا، وكان التوقيت مهمًا. إذا فاتتك حالة حافة واحدة، فسيظل تلميح الأداة مفتوحًا لفترة طويلة جدًا أو يختفي قبل أن تتمكن من قراءته. مع تعيين السمة المنبثقة على تلقائي أو يدوي، يتولى المتصفح الأساسيات: يعمل Tab و Shift+Tab بشكل طبيعي، ويغلق Esc تلميح الأداة في كل مرة، ولا يلزم وجود مستمعين إضافيين.
ما اختفى من قاعدة التعليمات البرمجية الخاصة بي هو معالجات المفاتيح العامة، ومنطق التنظيف الخاص بـ Esc، والتحقق من الحالة أثناء التنقل عبر لوحة المفاتيح. توقفت تجربة لوحة المفاتيح عن كونها شيئًا يجب علي الحفاظ عليه، وأصبحت ضمانًا للمتصفح. 2. القدرة على التنبؤ بقارئ الشاشة كان هذاأكبر تحسن. حتى مع عمل ARIA الدقيق، كان السلوك يختلف، كما أوضحت سابقًا. كان كل تغيير صغير يبدو محفوفًا بالمخاطر. يبدو استخدام النافذة المنبثقة مع الدور المناسب أكثر استقرارًا وقابلية للتنبؤ به فيما يتعلق بما سيحدث:
وهنا فوز آخر: بعد التبديل، توقف Lighthouse عن وضع علامة على تحذيرات حالة ARIA غير الصحيحة للتفاعل، ويرجع ذلك إلى حد كبير إلى عدم وجود حالات ARIA مخصصة لأخطئ فيها عن طريق الخطأ.
3. إدارة التركيز كان التركيز هشا. من قبل، كانت لدي قواعد مثل: السماح لمشغل التركيز بإظهار تلميح الأداة، ونقل التركيز إلى تلميح الأداة وعدم إغلاقه، وطمس المشغل عندما يكون قريبًا جدًا، وإغلاق تلميح الأداة واستعادة التركيز يدويًا. لقد نجح هذا حتى لم يحدث ذلك. باستخدام Popover API، يفرض المتصفح نموذجًا أبسط حيث يمكن أن ينتقل التركيز بشكل طبيعي إلى العنصر المنبثق. يؤدي إغلاق العنصر المنبثق إلى إرجاع التركيز إلى المشغل، ولا توجد مصائد تركيز غير مرئية أو لحظات تركيز مفقودة. ولم أقم بإضافة كود استعادة التركيز؛ لقد قمت بإزالته.
الاستنتاج تعني واجهة Popover API أن تلميحات الأدوات لم تعد شيئًا يمكنك محاكاته. إنها شيء يفهمه المتصفح. الفتح والإغلاق وسلوك لوحة المفاتيح والتعامل مع الهروب وجزء كبير من إمكانية الوصول يأتي الآن من النظام الأساسي نفسه، وليس من JavaScript المخصص. هذا لا يعني أن مكتبات تلميحات الأدوات أصبحت قديمة لأنها لا تزال منطقية بالنسبة لأنظمة التصميم المعقدة، أو التخصيصات الثقيلة، أو القيود القديمة، ولكن الوضع الافتراضي قد تغير. ولأول مرة، يمكن أن تكون أبسط تلميحات الأدوات هي الأكثر صحة أيضًا. إذا كنت مهتمًا بالفضول، فجرّب هذه التجربة: ما عليك سوى استبدال تلميح أداة واحد فقط في منتجك بواجهة برمجة تطبيقات Popover، ولا تعيد كتابة كل شيء، ولا تقم بترحيل النظام بأكمله، واختر واحدًا فقط وشاهد ما يختفي من التعليمات البرمجية الخاصة بك. عندما تمنحك المنصة بدائية أفضل، فإن الفوز لا يقتصر على عدد أقل من أسطر جافا سكريبت، بل هو عدد أقل من الأشياء التي يجب أن تقلق بشأنها على الإطلاق. تحقق من كود المصدر الكامل في مستودع GitHub الخاص بي. مزيد من القراءة للتعمق أكثر في النوافذ المنبثقة وواجهات برمجة التطبيقات ذات الصلة:
"بوبين إن"، جيف جراهام "توضيح العلاقة بين Popovers ومربعات الحوار"، زيل ليو "ما هو popover = تلميح؟"، أونا كرافيتس "أوامر المستدعي"، دانيال شوارتز "إنشاء إشعار إغلاق تلقائي باستخدام HTML Popover"، بريثي افتح أداة شرح واجهة برمجة التطبيقات Popover API "فرقعة (فوق) البالونات"، جون ريا "وضع مرساة CSS"، خوان دييغو رودريغيز
تقدم MDN أيضًا وثائق فنية شاملة لـ Popover API.
