עצות כלים מרגישות כמו בעיית ממשק המשתמש הקטנה ביותר שיכולה להיות לך. הם זעירים ובדרך כלל נסתרים. כשמישהו שואל איך לבנות אחד, התשובה המסורתית כמעט תמיד חוזרת באמצעות ספריית JavaScript כלשהי. ובמשך זמן רב זו הייתה העצה ההגיונית. גם אני עקבתי אחריו. על פני השטח, טיפים פשוטים. העבר את העכבר או התמקד באלמנט, הצג תיבה קטנה עם טקסט כלשהו, ואז הסתר אותה כשהמשתמש מתרחק. אבל ברגע שאתה שולח אחד למשתמשים אמיתיים, הקצוות מתחילים להופיע. משתמשי מקלדת לוחצים על הדק, אך לעולם לא רואים את הסבר הכלי. קוראי מסך מכריזים על כך פעמיים, או בכלל לא. הסבר הכלי מהבהב כאשר אתה מזיז את העכבר מהר מדי. זה חופף תוכן במסכים קטנים יותר. לחיצה על Esc לא סוגרת אותו. הפוקוס הולך לאיבוד. עם הזמן, קוד ההסבר שלי גדל למשהו שלא ממש רציתי להחזיק בו יותר. מאזיני האירוע נערמו. ריחוף ופוקוס היו צריכים להיות מטופלים בנפרד. לחיצות חיצוניות דרשו מקרים מיוחדים. תכונות ARIA היו צריכים להישמר מסונכרנים ביד. כל תיקון קטן הוסיף עוד שכבה של היגיון. ספריות עזרו, אבל הן גם היו יותר כמו קופסאות שחורות שעבדתי סביבן במקום להבין לגמרי מה קורה מאחורי הקלעים. זה מה שדחף אותי להסתכל על ה-API החדש יותר של Popover. רציתי לראות מה יקרה אם אבנה מחדש הסבר כלים יחיד באמצעות המודל המקורי של הדפדפן ללא עזרת ספריה. כשאנחנו מתחילים, ראוי לציין שכמו בכל תכונה חדשה, יש כמה דברים עם זה שעדיין מגוהצים. עם זאת, כרגע הוא נהנה מתמיכה מצוינת בדפדפן, למרות שיש כמה חלקים ב-API הכולל שנמצאים בתנופה. שווה לפקוח עין על קניוס בינתיים. הסבר הכלי "הישן". לפני ה-Popover API, השימוש בספריית טיפים לא היה קיצור דרך. זה היה ברירת המחדל. לדפדפנים לא היה מושג מקורי של הסבר כלים שעבד בעכבר, מקלדת וטכנולוגיה מסייעת. אם אכפת לך מהנכונות, האפשרות היחידה שלך הייתה להשתמש בספרייה, וזה בדיוק מה שעשיתי. ברמה גבוהה, הדפוס תמיד היה זהה: אלמנט טריגר, אלמנט הסבר כלים מוסתר ו-JavaScript לתיאום בין השניים.
הספרייה טיפלה בחיווט שאיפשר לרכיב להופיע ברחף או במיקוד, להסתתר בטשטוש או ביציאה מהעכבר, ולשנות מיקום/שינוי גודל בגלילה.
עם הזמן, קצה הכלים עלול להיות שביר. שינויים קטנים נשאו סיכון. תיקונים קלים גרמו לרגרסיה. גרוע מכך, הוספת עצות כלים חדשות ירשה את אותה מורכבות. הדברים עבדו טכנית, אבל מעולם לא הרגישו מסודרים או שלמים. זה היה מצב הדברים כאשר החלטתי לבנות מחדש את הסבר הכלים באמצעות ה-Popover API המקורי של הדפדפן. הרגע שבו ניסיתי את ה-API של Popover לא עברתי להשתמש ב-Popover API כי רציתי להתנסות במשהו חדש. החלפתי כי נמאס לי לשמור על התנהגות של טיפים של כלים שהאמנתי שהדפדפן כבר היה צריך להבין. הייתי סקפטי בהתחלה. רוב ממשקי ה-API החדשים של האינטרנט מבטיחים פשטות, אך עדיין דורשים דבק, טיפול במקרי קצה או היגיון חוזר שמשחזר בשקט את אותה מורכבות שניסית לחמוק ממנה. אז ניסיתי את ה-API של Popover בצורה הכי קטנה שאפשר. כך זה נראה:
1. המקלדת "פשוט עובדת" תמיכת המקלדת הייתה תלויה בשכבות מרובות שהתייצבו בצורה נכונה: המיקוד היה צריך להפעיל את הסבר הכלים, הטשטוש היה צריך להסתיר אותו, Esc היה צריך להיות חוטי ידני, והתזמון היה חשוב. אם פספסת מקרה קצה אחד, הסבר הכלי יישאר פתוח יותר מדי או ייעלם לפני שניתן היה לקרוא אותו. כאשר תכונת ה-popover מוגדרת לאוטומטית או ידנית, הדפדפן משתלט על היסודות: Tab ו-Shift+Tab מתנהגים כרגיל, Esc סוגר את הסבר הכלי בכל פעם, ואין צורך במאזינים נוספים.
מה שנעלם מבסיס הקוד שלי היו מטפלי מקלדת גלובליים, לוגיקה ספציפית לניקוי Esc ובדיקות מצב במהלך ניווט במקלדת. חווית המקלדת הפסיקה להיות משהו שהייתי צריך לתחזק, והיא הפכה לערבות דפדפן. 2. חיזוי קורא מסך זה היה ההשיפור הגדול ביותר. אפילו עם עבודת ARIA זהירה, ההתנהגות השתנתה, כפי שתיארתי קודם. כל שינוי קטן הרגיש מסוכן. השימוש בפופ-אובר עם תפקיד מתאים נראה ומרגיש הרבה יותר יציב וצפוי מבחינת מה שהולך לקרות:
והנה עוד ניצחון: לאחר המעבר, Lighthouse הפסיקה לסמן אזהרות שגויות של מצב ARIA עבור האינטראקציה, בעיקר בגלל שכבר אין מצבי ARIA מותאמים אישית כדי לטעות בטעות.
3. ניהול מיקוד פעם הפוקוס היה שביר. לפני כן, היו לי כללים כמו: לתת להפעיל את המיקוד להראות תיאור כלים, להעביר את הפוקוס לתוך תיאור הכלים ולא לסגור, לטשטש את ההדק כשהוא קרוב מדי, ולסגור את הסבר הכלים ולשחזר את המיקוד באופן ידני. זה עבד עד שלא. עם ה-Popover API, הדפדפן אוכף מודל פשוט יותר שבו המיקוד יכול לעבור באופן טבעי יותר לתוך ה-Popover. סגירת הפופ-אובר מחזירה את הפוקוס להדק, ואין מלכודות פוקוס בלתי נראות או רגעי פוקוס אבודים. ולא הוספתי קוד שחזור פוקוס; הסרתי אותו.
מסקנה ה-Popover API אומר שטיפים לכלים הם כבר לא משהו שאתה מדמה. הם משהו שהדפדפן מבין. פתיחה, סגירה, התנהגות מקלדת, טיפול בבריחה וחלק גדול של נגישות מגיעים כעת מהפלטפורמה עצמה, לא מ-JavaScript אד-הוק. זה לא אומר שספריות טיפים מיושנות כי הן עדיין הגיוניות עבור מערכות עיצוב מורכבות, התאמה אישית כבדה או אילוצים מדור קודם, אבל ברירת המחדל השתנתה. בפעם הראשונה, הסבר הכלי הפשוט ביותר יכול להיות גם הנכון ביותר. אם אתה סקרן, נסה את הניסוי הזה: פשוט החלף רק הסבר אחד במוצר שלך ב-Popover API, אל תכתוב הכל מחדש, אל תעביר מערכת שלמה, ופשוט בחר אחת וראה מה נעלם מהקוד שלך. כאשר הפלטפורמה נותנת לך פרימיטיבי טוב יותר, הניצחון הוא לא רק פחות שורות של JavaScript, אלא זה פחות דברים שאתה צריך לדאוג לגביהם בכלל. בדוק את קוד המקור המלא במאגר GitHub שלי. קריאה נוספת לצלילה מעמיקה יותר לתוך פופ-אוברים וממשקי API קשורים:
"Poppin' In", ג'וף גרהם "הבהרת הקשר בין פופ-אוברים ודיאלוגים", זל ליו "מה זה פופ-אובר=רמז?", אונה קרבטס "פקודות מעורר", דניאל שוורץ "יצירת הודעת סגירה אוטומטית עם HTML Popover", Preethi פתח את ממשק המשתמש Popover API Explainer "הקפיץ (מעל) את הבלונים", ג'ון ריאה "מיקום עוגן CSS", חואן דייגו רודריגז
MDN מציעה גם תיעוד טכני מקיף עבור ה-API של Popover.
