राजभाषा के इर्द-गिर्द बहुत बकबक' <details> और <summary> तत्व हाल ही में! मैंने देखा ली वेरो ने हाल ही में एक अवलोकन ट्वीट किया तत्व के बारे में display व्यवहार और उस तरह के लोगों से अधिक टिप्पणियों और उपयोग नोटों में विभाजित हो गया, जिसमें a . भी शामिल है पुनर्जीवित चर्चा चाहे पर <summary> इंटरैक्टिव तत्वों को शामिल करने की अनुमति दी जानी चाहिए या नहीं।
कनेक्ट करने के लिए बहुत सारे बिंदु हैं और मैं ठीक वैसा ही करने के लिए यहां अपनी पूरी कोशिश करूंगा।
क्या हम में नेस्टेड तत्वों के प्रदर्शन को बदल सकते हैं <details> तत्व?
सुपर अजीब! यदि हम खुले DevTools को क्रैक करते हैं, तो उपयोगकर्ता एजेंट स्टाइलशीट हमें बताता है <details> एक ब्लॉक तत्व के रूप में प्रदर्शित किया जाता है।
आवश्यक ध्यान दें <summary> तत्व और दो अतिरिक्त <div>वहाँ में एस। हम ओवरराइड कर सकते हैं display, सही?
हम जो उम्मीद कर सकते हैं वह यह है कि <details> अब की स्पष्ट ऊंचाई है 40vh और तीन पंक्तियाँ जहाँ तीसरी पंक्ति पहले दो से बचे हुए स्थान पर कब्जा कर लेती है। ऐशे ही:
उह, लेकिन तीसरी पंक्ति नहीं... करती है... वह।
जाहिरा तौर पर हम जो काम कर रहे हैं वह एक ग्रिड कंटेनर है जो ग्रिड व्यवहार को अपने ग्रिड आइटम पर लागू करने में असमर्थ है। लेकिन HTML युक्ति हमें बताती है:
RSI
detailsतत्व है एक के रूप में प्रस्तुत करने की उम्मीद है ब्लॉक बॉक्स. तत्व के आंतरिक होने की भी अपेक्षा की जाती है छाया वृक्ष दो के साथ स्लॉट्स.(जोर मेरा)
और थोड़ी देर बाद:
RSI
detailsतत्व का दूसरा स्लॉट इसके होने की उम्मीद हैstyleविशेषता "पर सेटdisplay: block; content-visibility: hidden;" जबdetailsतत्व में एक नहीं हैopenविशेषता। जब उसके पासopenविशेषता,styleविशेषता दूसरे से हटाए जाने की उम्मीद है स्लॉट.(जोर मेरा, फिर से)
तो, कल्पना दूसरा स्लॉट कहती है - दो अतिरिक्त <div>उदाहरण से - केवल ब्लॉक तत्वों के रूप में मजबूर किया जाता है जब <details> बन्द है। जब यह खुला हो - <details open> - उन्हें ग्रिड डिस्प्ले के अनुरूप होना चाहिए जो उपयोगकर्ता एजेंट स्टाइल को ओवरराइड करता है ... है ना?
यही बहस है। मै समझ गया slots पर सेट हैं display: contents डिफ़ॉल्ट रूप से, लेकिन नेस्टेड तत्वों को स्लॉट में जाम करना और उन्हें स्टाइल करने की क्षमता को हटाना बंद लगता है। क्या यह एक विशिष्ट समस्या है कि सामग्री स्लॉट हैं, या एक ब्राउज़र समस्या है जिसे हम ओवरराइड नहीं कर सकते हैं display भले ही वे बॉक्स ट्री में हों? होशियार लोग मुझे प्रबुद्ध कर सकते हैं लेकिन यह गलत कार्यान्वयन जैसा लगता है।
Is <details> एक कंटेनर या एक इंटरैक्टिव तत्व?
बहुत सारे लोग हैं का उपयोग <details> मेनू टॉगल करने के लिए खुला और बंद। यह एक अभ्यास है GitHub . द्वारा लोकप्रिय.
वाजिब लगता है। युक्ति निश्चित रूप से इसकी अनुमति देती है:
RSI
detailsतत्व का प्रतिनिधित्व करता है एक प्रकटीकरण विजेट जिससे उपयोगकर्ता अतिरिक्त जानकारी प्राप्त कर सकता है या नियंत्रण.(जोर मेरा)
ठीक है, तो हम उम्मीद कर सकते हैं कि <details> कंटेनर है (इसमें an . है) अंतर्निहित role=group) और <summary> एक संवादात्मक तत्व है जो कंटेनर को सेट करता है open राज्य। तब से समझ में आता है <summary> एक निहित है button भूमिका कुछ संदर्भों में (लेकिन कोई संगत WAI-ARIA भूमिका नहीं)।
परंतु मेलानी सुमनेर ने कुछ खुदाई की यह न केवल इसका खंडन करता प्रतीत होता है, बल्कि इस निष्कर्ष की ओर ले जाता है कि उपयोग करना <details> एक मेनू के रूप में शायद सबसे अच्छी बात नहीं है। देखें क्या होता है जब <details> के बिना प्रदान किया जाता है <summary> तत्व:
यह ठीक वैसा ही करता है जैसा कि विनिर्देश बताता है कि यह गायब है a <summary> - यह अपना बनाता है:
पहला पोस्ट
summaryतत्व का तत्व बच्चा, यदि कोई, का प्रतिनिधित्व करता है विवरण का सारांश या किंवदंती। अगर कोई बच्चा नहीं हैsummaryतत्व, उपयोगकर्ता एजेंट को अपनी किंवदंती प्रदान करनी चाहिए (उदाहरण के लिए "विवरण")।(जोर मेरा)
मेलानी ने इसे एक HTML सत्यापनकर्ता के माध्यम से चलाया और - आश्चर्य! - यह अमान्य है:
तो, <details> की आवश्यकता है <summary>. और कब <summary> लापता है, <details> इसे स्वयं बनाता है, हालांकि इसे अमान्य मार्कअप के रूप में रिले किया गया है। यह सब हंकी-डोरी है और मान्य है जब <summary> है:
यह सब एक नए प्रश्न की ओर ले जाता है: यही वजह है कि <summary> एक निहित button भूमिका जब <details> क्या इंटरैक्टिव तत्व प्रतीत होता है? शायद यह एक और मामला है जहां ब्राउज़र कार्यान्वयन गलत है? फिर फिर, कल्पना दोनों को वर्गीकृत करती है इंटरैक्टिव तत्वों. आप देख सकते हैं कि यह सब कितना भ्रमित करने वाला हो जाता है।
किसी भी तरह, मेलानी का अंतिम निष्कर्ष जिसे हमें उपयोग करने से बचना चाहिए <details> मेनू के लिए सहायक तकनीक कैसे पढ़ती और घोषणा करती है, इस पर आधारित है <details> जिसमें संवादात्मक तत्व होते हैं। तत्व की घोषणा की गई है, लेकिन इससे परे इंटरैक्टिव नियंत्रणों का कोई उल्लेख नहीं है जब तक कि आप, एर, बातचीत साथ में <details>. उसके बाद ही लिंक्स की सूची जैसा कुछ घोषित किया जाएगा।
इसके अलावा, एक ध्वस्त के अंदर की सामग्री <details> इन-पेज खोज से बाहर रखा गया है (क्रोमियम ब्राउज़र को छोड़कर, जो लेखन के समय संक्षिप्त सामग्री तक पहुंच सकता है), जिससे चीजों को ढूंढना और भी मुश्किल हो जाता है।
तैयार करनी चाहिए या <summary> इंटरैक्टिव तत्वों की अनुमति दें?
यही प्रश्न में रखा गया है यह खुला धागा. विचार यह है कि ऐसा कुछ अमान्य होगा:
<details>
<summary><a href="...">Link element</a></summary>
</details>
<!-- or -->
<details>
<summary><input></summary>
</details>स्कॉट ओ'हारा अच्छी तरह से सारांश यह एक मुद्दा क्यों है:
लिंक अपने वर्चुअल कर्सर के साथ नेविगेट करते समय JAWS के लिए बिल्कुल भी खोजने योग्य नहीं है। यदि टैब कुंजी के माध्यम से सारांश तत्व पर नेविगेट किया जाता है, तो JAWS तत्व के नाम और भूमिका के रूप में "उदाहरण टेक्स्ट, बटन" की घोषणा करता है। यदि टैब कुंजी को फिर से मारते हैं, तो JAWS फिर से "उदाहरण टेक्स्ट, बटन" की घोषणा करता है, भले ही कीबोर्ड फोकस लिंक पर हो।
[...]
सारांश के लिए सामग्री मॉडल के साथ एटी की विभिन्न समस्याओं के बारे में और भी बहुत कुछ हो सकता है ... लेकिन यह इस टिप्पणी को आवश्यक से आगे बढ़ा देगा। टीएलडीआर; सारांश सामग्री मॉडल एटी का उपयोग करने वाले लोगों के लिए बहुत असंगत और कभी-कभी केवल टूटे हुए अनुभवों को उत्पन्न करता है।
स्कॉट ने इस व्यवहार को ठीक करने के लिए टिकट खोले क्रोमियम और वेबकिट. धन्यवाद, स्कॉट!
फिर भी, यह मान्य HTML है:
स्कॉट आगे बढ़ता है अलग ब्लॉग पोस्ट. उदाहरण के लिए, वह बताता है कि कैसे थप्पड़ मारना role=button on <summary> यह सुनिश्चित करने के लिए एक उचित समाधान की तरह लग सकता है कि सहायक तकनीक द्वारा इसकी लगातार घोषणा की जाती है। यह इस बहस को भी सुलझाएगा कि क्या <summary> इंटरैक्टिव तत्वों की अनुमति देनी चाहिए क्योंकि बटन में इंटरैक्टिव तत्व नहीं हो सकते हैं. एकमात्र समस्या यह है कि सफारी तब व्यवहार करती है <summary> एक मानक बटन के रूप में, जो इसे खो देता है expanded और collapsed राज्यों। तो, सही भूमिका की घोषणा की जाती है, लेकिन अब इसकी स्थिति नहीं है। मैं
अब हम कहा जाएं?
क्या आप इस्तेमाल करने से डरते हैं <details>/<summary> इन सभी मुद्दों और विसंगतियों के साथ? मुझे यकीन है, लेकिन केवल यह सुनिश्चित करने के लिए कि इसमें क्या है, उपयोगकर्ताओं के लिए सही प्रकार का अनुभव और अपेक्षाएं प्रदान करता है।
मुझे खुशी है कि ये बातचीत हो रही है और खुले में हो रही है। उसके कारण, आप स्कॉट के तीन प्रस्तावित समाधानों पर टिप्पणी कर सकते हैं कि कैसे सामग्री मॉडल के लिए <summary> परिभाषित किया गया है, उसके टिकटों को ऊपर उठाएं, और अपने मुद्दों की रिपोर्ट करें और जब आप इस पर हों तो मामलों का उपयोग करें। उम्मीद है, जितना बेहतर हम समझते हैं कि तत्वों का उपयोग कैसे किया जाता है और हम उनसे क्या करने की उम्मीद करते हैं, उन्हें बेहतर तरीके से लागू किया जाता है।
