ממשק ה-API של חלונות קופצים זמין עכשיו בגרסה הבסיסית

תאריך פרסום: 7 בפברואר 2025

באפריל 2024, בפוסט באתר הזה הודענו ש-Popover API זמין עכשיו בגרסה Baseline. עם זאת, טעינו, והחלונית הקופצת תעבור ל-Baseline החל מ-27 בינואר 2025. בפוסט הזה נסביר למה טעינו, ומה השתנה מאז כדי לצמצם את הסבירות לטעויות כאלה.

מהו Popover API?

‏Popover API מספק דרך מובנית ליצירת סוגים שונים של חלונות קופצים שמשמשים באפליקציות אינטרנט. בעבר, כדי להשתמש בהם היה צריך להשתמש ב-JavaScript, ולהקפיד מאוד על הטמעה בצורה נגישה. ה-API מעביר את כל זה לדפדפן, וניתן ליצור חלון קופץ פשוט באופן דקלרטיבי ב-HTML.

<button popovertarget="my-popover">Open Popover</button>

<div id="my-popover" popover>
  <p>I am a popover with more information. Hit <kbd>esc</kbd> or click away to close me.</p>
</div>
דוגמה בסיסית לשימוש במאפיין popover.

למה לא הוצגה אותה כבסיס להשוואה באפריל 2024?

כש-Firefox השיקה את ההטמעה של חלונות קופצים באפריל 2024, עדיין לא זיהינו בעיה משמעותית ב-iOS וב-iPadOS. בדפדפנים לנייד האלה, לחיצה מחוץ לחלון הקופץ לא סגרה אותו, תכונה שנקראת סגירה קלה. זו בעיה שמונעת מרוב המפתחים להשתמש ב-popover. המשמעות היא שלא היה צריך לכלול אותה כבסיס בחודש אפריל, והיה צריך לחכות עד לתיקון הבאג ב-Safari 18.3.

למה טעינו?

כדי לחשב מתי תכונות נכללות ב-Baseline או לא, המערכת מסתמכת על העבודה של web-features. אם תעיינו בקובץ תכונה ספציפי בפרויקט הזה, כמו הקובץ של חלון קופץ, תוכלו לראות את התכונות הנפרדות מנתוני התאימות לדפדפנים של Mozilla. בדרך כלל, תכונה אחת באינטרנט מכילה כמה מהתכונות האלה. הסיבה לכך היא שתכונה באינטרנט היא לא רק נכס או שיטה אחת, אלא היא מורכבת מכמה רכיבים. תכונה היא גם לא מפרט שלם. לדוגמה, מפרטי CSS כוללים לרוב תכונות משנה שלא יושמו אף פעם, או תכונות שמשמשות רק בהקשר ספציפי. כדי לבדוק מה נחשב לתכונה של פלטפורמת אינטרנט, וחשוב מכך, אם הטמעה חלקית היא חמורה מספיק כדי לא לכלול אותה ב-Baseline, אנחנו משתמשים בשילוב של נתוני זמינות קיימים ומשוב אנושי.

בפברואר, העבודה על התכונות לאינטרנט הייתה רחוקה מלהסתיים. לכן, כדי להראות איך Baseline יפעל, ניסינו לזהות תכונות מרכזיות שייכללו ב-Baseline 2024 בלי כל הנתונים שנדרשו לנו כדי לעשות זאת. על הנייר, או ליתר דיוק בנתוני התאימות לדפדפנים שלא עודכנו עד ספטמבר, כשהבעיה זוהתה, נראה שהתכונה 'חלון קופץ' כלולה. עם זאת, בגלל שהבאג ב-iOS היה חמור מספיק כדי למנוע שימוש בחלון קופץ, הוא לא היה מוכן.

בנוסף, לא הייתה תשתית בדיקה למכשירים ניידים. הפרויקט Web Platform Tests מאפשר לנו לבדוק אם התכונות של פלטפורמת האינטרנט פועלות בכל הדפדפנים. אם הבעיה הזו בביטול התראות באמצעות תנועת אור הייתה מתרחשת בדפדפן במחשב, היינו רואים שהבדיקות נכשלו, אבל זה לא קרה בנייד.

איך נוכל למנוע את זה בעתיד?

אנחנו כבר במקום הרבה יותר טוב עם הנתונים. הנתונים של תכונות האינטרנט כמעט מלאים, ולכן יש לנו רמת ביטחון גבוהה יותר לגבי כל התכונות שאנחנו מגדירים כבסיס.

במקרה הזה, חלק מהבעיה היה זיהוי בעיה שמתרחשת רק בנייד, ב-iOS. אנחנו עושים כמה דברים שיעזרו לנו לזהות בקלות רבה יותר בעיות של יכולת פעולה הדדית בנייד בעתיד. אנחנו עובדים על שיפור הבדיקות בניידים בבדיקות של פלטפורמת האינטרנט, כדי שנוכל לזהות טוב יותר מתי יש בעיות בדפדפן בנייד, בנפרד מהמחשב. אנחנו גם מתכננים להציג את הנתונים האלה במרכז הבקרה webstatus.dev השנה. אם בעיה כזו תתרחש בעתיד, אנחנו אמורים לקבל אינדיקציות מהירות יותר לכך, ורצוי לפני שנכלול את התכונה ב-Baseline.

תמיד ידענו שמיפוי כל פלטפורמת האינטרנט כקבוצת תכונות לא יהיה קל. עם זאת, הדיונים שלנו על הטמעות חלקיות, באגים ומה שמרכיב בפועל תכונה הם חשובים מאוד. הנתונים האלה עוזרים לנו לזהות מה באמת חשוב לכם, ומספקים לנו אותות טובים יותר לשימוש כשאנחנו מתכננים אירועים כמו Interop 2025.