פרטים נוספים על `פרטים`

הרבה פטפוטים מסביב לעולם <details> ו <summary> אלמנטים לאחרונה! ראיתי לאה וורו צייצה לאחרונה תצפית לגבי האלמנט display התנהגות וזה די התפצל ליותר תצפיות והערות שימוש של אנשים, כולל א החייאה את הדיון בשאלה אם <summary> צריך לאפשר להכיל אלמנטים אינטראקטיביים או לא.

יש הרבה נקודות לחיבור ואני אעשה כאן כמיטב יכולתי לעשות בדיוק את זה.

האם נוכל לשנות את תצוגת האלמנטים המקוננים ב- <details> אֵלֵמֶנט?

באפליקציה שאני בונה אני משתמש עבור פאנלים אבל נתקלתי באיזו מוזרות בגודל.
פלקסבוקס: https://t.co/noZvxAN35G
רשת: https://t.co/pis0lPjvXk
בהתחלה חשבתי שזה באג, אבל כל שלושת המנועים מסכימים. שום דבר בגיליון הסגנונות של UA עבור נראה להסביר את זה.

- לאה וורו (@LeaVerou) אוגוסט

סופר מוזר! אם נפצח את DevTools, גיליון הסגנונות של סוכן המשתמש אומר לנו <details> הוא מוצג כאלמנט בלוק.

שימו לב לדרוש <summary> אלמנט והשניים הנוספים <div>נמצא שם. אנחנו יכולים לעקוף את display, ימין?

מה שאנחנו יכולים לצפות זה לזה <details> כעת יש גובה מפורש של 40vh ושלוש שורות שבהן השורה השלישית תופסת את השטח שנותר מהשתיים הראשונות. ככה:

אוף, אבל השורה השלישית לא... עושה... את זה.

ככל הנראה מה שאנו עוסקים בו הוא מיכל רשת שאינו מסוגל להחיל התנהגות רשת על פריטי הרשת שלו. אבל מפרט ה-HTML אומר לנו:

השמיים details אלמנט הוא צפוי לעבד בתור א תיבת בלוק. לאלמנט צפוי גם להיות פנימי עץ צל עם שתיים חריצי.

(הדגש שלי)

וקצת אחר כך:

השמיים details השני של האלמנט חריץ צפוי לקבל את שלו style התכונה מוגדרת ל"display: block; content-visibility: hidden;" כאשר details לאלמנט אין an open תכונה. כאשר יש לו את open תכונה, ה style התכונה צפויה להיות מוסרת מהשנייה חריץ.

(הדגש שלי, שוב)

אז המפרט אומר שהחריץ השני - השניים הנוספים <div>s מהדוגמה - נאלצים להיות אלמנטים בלוק רק כאשר <details> סגור. כשהוא פתוח - <details open> - הם צריכים להתאים לתצוגת הרשת שעוקפת את הסגנון של סוכן המשתמש... נכון?

זה הוויכוח. אני מבין את זה slots נקבעים display: contents כברירת מחדל, אבל השבתת אלמנטים מקוננים לתוך חריצים והסרת היכולת לסגנן אותם נראה כבוי. האם זו בעיה במפרט שהתוכן הוא משבצות, או בעיית דפדפן שאיננו יכולים לעקוף אותן display למרות שהם בעץ הקופסה? אנשים חכמים יותר יכולים להאיר אותי אבל זה נראה כמו יישום לא נכון.

Is <details> מיכל או אלמנט אינטראקטיבי?

הרבה אנשים כן באמצעות <details> כדי להחליף תפריטים פתוח וסגור. זה תרגול פופולרי על ידי GitHub.

נראה הגיוני. המפרט בהחלט מאפשר זאת:

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

(הדגש שלי)

בסדר, אז אולי אנחנו מצפים לזה <details> הוא המיכל (יש לו משתמע role=group) ו <summary> הוא אלמנט אינטראקטיבי שקובע את ה-container open מדינה. הגיוני מאז <summary> יש השלכה button תפקיד בהקשרים מסוימים (אך ללא תפקיד WAI-ARIA מקביל).

אבל מלאני סאמנר עשתה קצת חפירה זה לא רק שנראה סותר את זה, אלא מוביל למסקנה ששימוש <details> מכיוון שתפריט הוא כנראה לא הדבר הטוב ביותר. תראה מה קורה מתי <details> מוצג ללא ה <summary> אֵלֵמֶנט:

זה עושה בדיוק מה שהמפרט מציע כשחסר לו א <summary> - זה עושה את שלו:

1 summary אלמנט בן האלמנט, אם בכלל, מייצג הסיכום או האגדה של הפרטים. אם אין ילד summary רכיב, סוכן המשתמש צריך לספק מקרא משלו (למשל "פרטים").

(הדגש שלי)

מלאני הריצה את זה דרך מאמת HTML ו- הפתעה! - זה לא חוקי:

אז, <details> דורש את <summary>. ומתי <summary> חסר, <details> יוצר משלו, אם כי הוא מועבר כסימון לא חוקי. זה הכל חרישי ותקף מתי <summary> האם יש:

כל אלה מובילים לשאלה חדשה: למה <summary> ניתנת השלכה button תפקיד מתי <details> האם מה שנראה כאלמנט האינטראקטיבי? אולי זה עוד מקרה שבו יישום הדפדפן שגוי? אז שוב, המפרט אכן מקטלג את שניהם כ אלמנטים אינטראקטיביים. אתה יכול לראות כמה מבלבל כל זה הופך להיות.

כך או כך, המסקנה הסופית של מלאני שעלינו להימנע משימוש בה <details> עבור תפריטים מבוסס על האופן שבו הטכנולוגיה המסייעת קוראת ומודיעה <details> המכילים אלמנטים אינטראקטיביים. האלמנט הוכרז, אבל אין אזכור לפקדים אינטראקטיביים מעבר לזה עד שאתה, אה, אינטראקציה עם <details>. רק אז יוכרז משהו כמו רשימת קישורים.

חוץ מזה, תוכן בתוך קרס <details> אינו נכלל בחיפוש בתוך הדף (למעט בדפדפני Chromium, שיכולים לגשת לתוכן המכווץ בזמן הכתיבה), מה שמקשה עוד יותר למצוא דברים.

צריך <summary> לאפשר אלמנטים אינטראקטיביים?

זו השאלה שנשאלה השרשור הפתוח הזה. הרעיון הוא שמשהו כזה יהיה לא חוקי:

<details>
  <summary><a href="...">Link element</a></summary>
</details>

<!-- or -->

<details>
  <summary><input></summary>
</details>

סקוט אוהרה מסכם יפה מדוע זו בעיה:

הקישור אינו ניתן לגילוי כלל ל-JAWS בעת ניווט עם הסמן הווירטואלי שלו. אם מנווטים לרכיב הסיכום באמצעות מקש Tab, JAWS מכריז על "טקסט לדוגמה, כפתור" בתור השם והתפקיד של האלמנט. אם לוחצים שוב על מקש Tab, JAWS שוב מכריז "טקסט לדוגמה, לחצן" למרות שהמיקוד במקלדת נמצא בקישור.

[...]

יש עוד דברים שאוכל להמשיך עליהם עם הבעיות השונות שיש ל-AT עם מודל התוכן לסיכום... אבל זה רק ירחיב את ההערה הזו מעבר למה שצריך. tldr; מודל התוכן המסכם מייצר חוויות מאוד לא עקביות ולעיתים פשוטות ופשוטות עבור אנשים שמשתמשים ב-AT.

סקוט פתח כרטיסים כדי לתקן את ההתנהגות הזו כרום ו WebKit. תודה, סקוט!

עם זאת, זה HTML חוקי:

סקוט הולך רחוק יותר ב-a פוסט בלוג נפרד. למשל, הוא מסביר איך סטירות role=button on <summary> עשוי להיראות כמו תיקון סביר כדי להבטיח שהוא יוכרז בעקביות על ידי טכנאי מסייע. זה גם יסדיר את הוויכוח אם <summary> צריך לאפשר אלמנטים אינטראקטיביים כי לחצנים אינם יכולים להכיל אלמנטים אינטראקטיביים. הבעיה היחידה היא שספארי אז מטפל <summary> ככפתור רגיל, שמאבד את שלו expanded ו collapsed מדינות. אז, התפקיד הנכון הוכרז, אבל עכשיו מצבו לא. 🙃

לאן אנחנו הולכים עכשיו?

האם אתה מפחד להשתמש <details>/<summary> עם כל הבעיות וחוסר העקביות האלה? אני בטוח שכן, אבל רק במידה כדי לוודא שמה שיש בו מספק את הסוג הנכון של חוויה וציפיות למשתמשים.

אני רק שמח שהשיחות האלה מתרחשות ושהן מתקיימות בשטח פתוח. בגלל זה, אתה יכול להגיב על שלושת הפתרונות המוצעים של סקוט לאופן שבו מודל התוכן עבור <summary> מוגדר, הצביע בעד הכרטיסים שלו, ודווח על בעיות ומקרי שימוש משלך בזמן שאתה בעניין. יש לקוות שככל שנבין טוב יותר כיצד נעשה שימוש באלמנטים ומה אנו מצפים מהם לעשות, כך הם מיושמים טוב יותר.