More Details on `รายละเอียด'

พูดคุยกันมากมายรอบเฒ่า <details> และ <summary> องค์ประกอบเมื่อเร็ว ๆ นี้! ฉันเห็น Lea Verou เพิ่งทวีตข้อสังเกต เกี่ยวกับองค์ประกอบ display พฤติกรรมและนั่นก็แยกย่อยเป็นข้อสังเกตและบันทึกการใช้งานจากผู้คนมากขึ้น รวมถึง a ฟื้นการสนทนา ขึ้นอยู่กับว่า <summary> ควรได้รับอนุญาตให้มีองค์ประกอบแบบโต้ตอบหรือไม่

มีจุดให้เชื่อมต่อมากมาย และฉันจะทำให้ดีที่สุดเพื่อทำสิ่งนั้น

เราสามารถเปลี่ยนการแสดงขององค์ประกอบที่ซ้อนกันใน <details> ธาตุ?

ในแอพที่ฉันกำลังสร้าง ฉันกำลังใช้ สำหรับแผง แต่พบความแปลกประหลาดบางอย่าง
เฟล็กซ์บ็อกซ์: https://t.co/noZvxAN35G
กริด: https://t.co/pis0lPjvXk
ตอนแรกฉันคิดว่ามันเป็นข้อผิดพลาด แต่ทั้งสามเครื่องยนต์เห็นด้วย ไม่มีอะไรในสไตล์ชีต UA สำหรับ ดูเหมือนจะอธิบายมัน

– ลีอา เวรู (@LeaVerou) สิงหาคม 28, 2022

สุดแปลก! หากเราเปิด DevTools สไตล์ชีตตัวแทนผู้ใช้จะบอกเรา <details> เป็นการแสดงเป็นองค์ประกอบบล็อก

สังเกตความจำเป็น <summary> องค์ประกอบและสองเพิ่มเติม <div>อยู่ในนั้น เราสามารถแทนที่ displayใช่มั้ย?

สิ่งที่เราคาดหวังได้ก็คือ <details> ตอนนี้มีความสูงที่ชัดเจนของ 40vh และสามแถวที่แถวที่สามใช้พื้นที่ที่เหลือจากสองแถวแรก แบบนี้:

เอ่อ แต่แถวที่สามไม่… ทำ… แบบนั้น

เห็นได้ชัดว่าสิ่งที่เรากำลังเผชิญคือคอนเทนเนอร์กริดที่ไม่สามารถใช้ลักษณะการทำงานของกริดกับรายการกริดได้ แต่ข้อมูลจำเพาะ HTML บอกเราว่า:

พื้นที่ details องค์ประกอบคือ คาดว่าจะแสดงผลเป็น a กล่องบล็อค. องค์ประกอบยังคาดว่าจะมีภายใน ต้นไม้เงา กับสอง สล็อต.

(เน้นของฉัน)

และอีกไม่นาน:

พื้นที่ details องค์ประกอบที่สอง สล็อต คาดว่าจะมี style แอตทริบิวต์ตั้งค่าเป็น “display: block; content-visibility: hidden;" เมื่อ details องค์ประกอบไม่มี open คุณลักษณะ เมื่อมี open คุณลักษณะ, the style แอตทริบิวต์ที่คาดว่าจะถูกลบออกจากวินาที สล็อต.

(เน้นของฉันอีกครั้ง)

ดังนั้นสเป็คบอกว่าช่องที่สอง — สองเพิ่มเติม <div>จากตัวอย่าง — ถูกบังคับให้เป็นองค์ประกอบบล็อกเท่านั้นเมื่อ <details> ถูกปิด. เมื่อเปิด- <details open> — ควรสอดคล้องกับการแสดงกริดที่แทนที่การจัดสไตล์ของตัวแทนผู้ใช้… ใช่ไหม

นั่นคือการอภิปราย ฉันเข้าใจ slots ตั้งไว้ display: contents โดยค่าเริ่มต้นแต่การติดขัดองค์ประกอบที่ซ้อนกันลงในช่องและการนำความสามารถในการจัดรูปแบบออกนั้นดูจะไม่เหมาะสม มันเป็นปัญหาข้อมูลจำเพาะที่เนื้อหาเป็นสล็อตหรือปัญหาเบราว์เซอร์ที่เราไม่สามารถแทนที่ของพวกเขา display แม้ว่าจะอยู่ในกล่องต้นไม้? คนที่ฉลาดกว่าสามารถให้ความกระจ่างแก่ฉันได้ แต่ดูเหมือนว่าการใช้งานที่ไม่ถูกต้อง

Is <details> คอนเทนเนอร์หรือองค์ประกอบแบบโต้ตอบ?

คนเยอะมาก การใช้ <details> เพื่อสลับเมนู เปิดและปิด มันคือการปฏิบัติ เป็นที่นิยมโดย GitHub.

ดูเหมือนสมเหตุสมผล ข้อมูลจำเพาะช่วยให้:

พื้นที่ details ธาตุ แสดงให้เห็นถึง วิดเจ็ตการเปิดเผยซึ่งผู้ใช้สามารถรับข้อมูลเพิ่มเติม หรือการควบคุม.

(เน้นของฉัน)

เอาล่ะ เราอาจคาดหวังได้ว่า <details> เป็นภาชนะ (มี an โดยปริยาย role=group) and <summary> เป็นองค์ประกอบแบบโต้ตอบที่กำหนดคอนเทนเนอร์ของ open สถานะ. สมเหตุสมผลตั้งแต่ <summary> มีความนัย button บทบาท ในบางบริบท (แต่ไม่มีบทบาท WAI-ARIA ที่สอดคล้องกัน)

แต่ Melanie Sumner ทำการขุด ที่ไม่เพียงแต่ดูเหมือนจะขัดแย้งกับสิ่งนั้นเท่านั้น แต่ยังนำไปสู่ข้อสรุปว่าการใช้ <details> เพราะเมนูอาจจะไม่ใช่สิ่งที่ดีที่สุด ดูว่าเกิดอะไรขึ้นเมื่อ <details> ถูกแสดงผลโดยไม่มี <summary> ธาตุ:

มันทำสิ่งที่สเป็คแนะนำเมื่อมันหายไป <summary> - มันทำขึ้นเอง:

ครั้งแรก summary องค์ประกอบลูกขององค์ประกอบ ถ้ามี, แสดงให้เห็นถึง สรุปหรือตำนานของรายละเอียด ถ้าไม่มีลูก summary องค์ประกอบ ตัวแทนผู้ใช้ควรระบุคำอธิบายของตนเอง (เช่น “รายละเอียด”)

(เน้นของฉัน)

Melanie เรียกใช้มันผ่านเครื่องมือตรวจสอบ HTML และ — แปลกใจ! — ไม่ถูกต้อง:

ดังนั้น <details> ต้องใช้ไฟล์ <summary>. และเมื่อ <summary> ที่ขาดหายไป, <details> สร้างเป็นของตัวเอง แม้ว่าจะถูกส่งต่อว่าเป็นมาร์กอัปที่ไม่ถูกต้อง มันดูงี่เง่าและใช้ได้เมื่อ <summary> อยู่ที่นั่น:

ทั้งหมดนี้นำไปสู่คำถามใหม่: ทำไม <summary> ให้โดยปริยาย button บทบาทเมื่อ <details> สิ่งที่ดูเหมือนจะเป็นองค์ประกอบแบบโต้ตอบคืออะไร? บางทีนี่อาจเป็นอีกกรณีที่การใช้งานเบราว์เซอร์ไม่ถูกต้อง จากนั้นอีกครั้ง ข้อมูลจำเพาะจะจัดหมวดหมู่ทั้งเป็น องค์ประกอบแบบโต้ตอบ. คุณสามารถดูได้ว่าทั้งหมดนี้ทำให้เกิดความสับสนได้อย่างไร

ไม่ว่าจะด้วยวิธีใด บทสรุปสุดท้ายของ Melanie ที่เราควรหลีกเลี่ยงการใช้ <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 ที่ถูกต้อง:

สกอตต์ไปต่อใน โพสต์บล็อกแยกต่างหาก. เช่น เขาอธิบายว่าตบอย่างไร role=button on <summary> อาจดูเหมือนเป็นการแก้ไขที่สมเหตุสมผลเพื่อให้แน่ใจว่าจะมีการประกาศอย่างสม่ำเสมอโดยเทคโนโลยีช่วยเหลือ ที่จะยุติการอภิปรายด้วยว่า <summary> ควรอนุญาตให้องค์ประกอบแบบโต้ตอบเพราะ ปุ่มไม่สามารถมีองค์ประกอบแบบโต้ตอบได้. ปัญหาเดียวคือ Safari นั้นปฏิบัติต่อ <summary> เป็นปุ่มมาตรฐานซึ่งสูญเสีย expanded และ collapsed รัฐ ดังนั้นจึงประกาศบทบาทที่ถูกต้อง แต่ตอนนี้สถานะของมันไม่ใช่ เ

เราจะไปที่ไหนตอนนี้

คุณกลัวที่จะใช้ <details>/<summary> กับปัญหาเหล่านี้และความไม่สอดคล้องกันทั้งหมด? ฉันแน่ใจ แต่เพียงเพื่อให้แน่ใจว่าสิ่งที่อยู่ในนั้นมอบประสบการณ์และความคาดหวังที่เหมาะสมแก่ผู้ใช้

ฉันแค่ดีใจที่การสนทนาเหล่านี้เกิดขึ้นและพวกเขากำลังเกิดขึ้นในที่เปิดเผย ด้วยเหตุนี้ คุณจึงสามารถแสดงความคิดเห็นเกี่ยวกับโซลูชันที่เสนอสามข้อของ Scott เกี่ยวกับวิธีการที่รูปแบบเนื้อหาสำหรับ <summary> ถูกกำหนด โหวตตั๋วของเขา และรายงานปัญหาของคุณเองและกรณีการใช้งานในขณะที่คุณดำเนินการอยู่ หวังว่ายิ่งเราเข้าใจวิธีการใช้องค์ประกอบและสิ่งที่เราคาดหวังให้พวกเขาทำมากขึ้นเท่าใด พวกเขาก็จะถูกนำไปใช้งานได้ดียิ่งขึ้น