`<dl>` के बारे में (2021)

 (benmyers.dev)
1 पॉइंट द्वारा GN⁺ 9 시간 전 | 2 टिप्पणियां | WhatsApp पर शेयर करें
  • `` नाम–मान जोड़ों की सूची को अर्थपूर्ण तरीके से व्यक्त करने वाला HTML एलिमेंट है, और सुविधाएँ, बिलिंग आइटम, तकनीकी शब्दावली जैसी UI patterns के लिए उपयुक्त है
  • description list की संरचना में नाम** और ** मान को `` के अंदर रखा जाता है, और एक ही नाम के साथ कई मान भी जोड़े जा सकते हैं
  • styling के लिए संबंधित और को समूहित करना हो, तो spec के अनुसार केवल `` wrapper ही उस group को घेर सकता है
  • सिर्फ nested का उपयोग करने पर assistive technology के लिए list pattern पहचानना कठिन हो सकता है, जबकि item count, current position और list skip जैसे navigation फायदे देता है
  • Dungeons & Dragons stat block की तरह अलग-अलग रूपों वाले numbers, abilities और actions data को भी description list में बाँटा जा सकता है, जिससे इसकी versatility स्पष्ट होती है

`` किस pattern को दर्शाता है

  • `` नाम–मान जोड़ों की सूची को दर्शाने वाला HTML एलिमेंट है, और वेब UI में बार-बार दिखने वाले pattern को semantic meaning देता है
  • lodging सुविधाएँ, monthly rent के अलग-अलग billing items, और technical glossary जैसी नाम और मान वाली संरचनाएँ इसके प्रतिनिधि उदाहरण हैं
  • कोई standalone एलिमेंट नहीं है; यह, , तीन एलिमेंट्स के संयोजन से नाम–मान groups बनाता है
  • HTML5 से पहले `` को definition list कहा जाता था, और मूल रूप से यह terms और definitions की glossary को व्यक्त करने के लिए बनाया गया था

description list की मूल संरचना

  • , , ``

    • **** पूरे description list को wrap करता है, और इसकी भूमिका कुछ हद तक या `` द्वारा पूरी सूची को घेरने जैसी है
    • ** description term है, जो नाम को दर्शाता है, और ** description detail है, जो मान को दर्शाता है
    • और पहले क्रमशः definition term और definition detail के नाम से भी जाने जाते थे
    • मूल संरचना में एक के बाद एक रखा जाता है

	Title
	Designing with Web Standards

  • कई नाम–मान जोड़े

    • उसी सूची में अन्य नाम–मान जोड़े जोड़ने के लिए नया और क्रम से रखा जाता है

	Title
	Designing with Web Standards
	Publisher
	New Riders Pub; 3rd edition (October 19, 2009)

  • एक नाम के कई मान

    • एक के साथ कई ** मान** हो सकते हैं
    • जैसे किसी किताब के कई authors हों, तो एक नाम के साथ कई मानों वाली संरचना को सीधे व्यक्त किया जा सकता है

	Title
	Designing with Web Standards
	Author
	Jeffrey Zeldman
	Ethan Marcotte
	Publisher
	New Riders Pub; 3rd edition (October 19, 2009)

  • styling के लिए wrapper

    • styling के उद्देश्य से संबंधित और को समूहित करना हो, तो `` wrapper का उपयोग किया जा सकता है
    • spec के अनुसार / group को wrap करने वाला एकमात्र wrapper एलिमेंट `` है
    • अधिक विस्तृत allowed structure और constraints के लिए MDN का `` दस्तावेज़ या HTML spec देखा जा सकता है

		Title
		Designing with Web Standards

		Author
		Jeffrey Zeldman
		Ethan Marcotte

semantics की ज़रूरत क्यों है

  • नाम–मान groups को केवल nested `` से भी दृश्य रूप में बनाया जा सकता है, लेकिन browser या assistive technology के लिए इसे list pattern के रूप में पहचानना कठिन होता है
  • semantic एलिमेंट का चयन इस आधार पर किया जा सकता है कि कंप्यूटर उस pattern को पहचानने पर उपयोगकर्ता को वास्तविक लाभ मिलता है या नहीं
  • `` का उपयोग करने पर screen reader users नाम–मान groups की सूची को अधिक आसानी से navigate कर सकते हैं
    • वे सूची में मौजूद नाम–मान groups की संख्या जान सकते हैं
    • वे समझ सकते हैं कि वे अभी सूची में किस स्थान पर हैं
    • यदि रुचि न हो, तो वे पूरी सूची को एक block की तरह skip कर सकते हैं
  • nested संरचना में हर नाम और मान अलग text node की तरह संभाला जाता है, लेकिन उसी जानकारी को संरचनात्मक अर्थ देता है
  • ये फायदे ज़्यादातर browser/screen reader combinations में `` के उपयोग पर वास्तव में मिलते हैं
  • हालाँकि support अभी पूरी तरह universal नहीं है, इसलिए यदि independent text nodes के रूप में fallback experience पर्याप्त नहीं है, तो support बेहतर होने तक जैसे दूसरे एलिमेंट चुनना भी उचित हो सकता है

Dungeons & Dragons stat block उदाहरण

  • Dungeons & Dragons का stat block नाम–मान जोड़ों का एक बड़ा उदाहरण है, और एक stat block के भीतर description list के कई संभावित उपयोग मिलते हैं
  • Armor Class, Hit Points, Speed जैसी basic values, STR·DEX जैसी abilities, Senses·Languages·Challenge जैसी proficiency-related information, तथा Traits और Actions को अलग-अलग description lists में बाँटा जा सकता है
  • दृश्य रूप से अलग दिखने वाली ability lists और attack lists भी description list pattern के रूप में व्यक्त की जा सकती हैं
  • कई description lists को अलग पहचान देने या उन्हें heading से जोड़ने के लिए aria-label और aria-labelledby का उपयोग किया जा सकता है
  • यह markup केवल एक संभावित तरीका है, और यह दिखाता है कि `` pattern अलग-अलग रूपों वाले data groups पर भी लागू होने लायक काफी versatile है

संबंधित पढ़ाई

2 टिप्पणियां

 
GN⁺ 6 시간 전
Lobste.rs की राय
  • अफ़सोस है कि Markdown में description list नहीं है
    • Pandoc-style Markdown कम-से-कम दो तरह के syntax में description list को support करता है
      लेकिन ज़्यादातर implementations इसे support नहीं करते, यह सही है। दूसरी ओर, typesetting system/markup language Typst / term: description जैसी syntax के साथ description list को first-class syntax के रूप में देता है, इसलिए यह - bullet list या + auto-numbered list के साथ भी अच्छी तरह मेल खाता है
    • याद है कि Hugo, Pandoc, GFM जैसी कुछ implementations इस तरह का form support करती हैं 
      dt  
: dd  

dt  
: dd
    • Markdown में HTML की हर चीज़ हो सकती है, क्योंकि यह HTML का superset है
    • https://www.djot.net/ description list को support करता है। और ज़्यादा महत्वपूर्ण बात यह है कि Djot HTML का superset नहीं है, इसलिए इसे भारी-भरकम HTML-supporting browser के बाहर भी इस्तेमाल किया जा सकता है
  • व्यक्तिगत रूप से यह अब तक के मेरे top five elements में आता है
    • <details> के साथ यह निश्चित रूप से ऊपर की श्रेणी में है। काश ऐसे interactive elements और ज़्यादा होते
  • एक item में कई <dt> भी रखे जा सकते हैं। dictionary-style list में synonym जैसी चीज़ें दिखाने के लिए इसका उपयोग हो सकता है
    CSS से styling करते समय adjacent sibling selector की आदत डालना अच्छा रहेगा
    संदर्भ: https://developer.mozilla.org/en-US/docs/…
 
GN⁺ 9 시간 전
Hacker News की राय

  • यह गलत है: के लिए कोई corresponding implicit role नहीं है, लेकिन इसे `group`, `list`, `none`, `presentation` role दिए जा सकते हैं `aria-label` सिर्फ़ उन elements पर define किया जा सकता है जिनके पास compatible role हो, चाहे implicit हो या explicit, और `aria-label` ज़्यादातर roles पर allowed है, लेकिन यहाँ `presentation` और `none` हट जाते हैं, इसलिए सिर्फ़ `group` और `list` बचते हैं `group` अटपटा है और `list` स्वीकार्य है, इसलिए निष्कर्ष यह है कि **या तो aria-label हटाएँ** या `role="list"` जोड़ें। तब children पर `role="listitem"` भी चाहिए होगा लेख में जो बात छूट गई, वह यह है कि सिर्फ़ एक बार नहीं आता, कई बार लगातार भी आ सकता है। spec का उदाहरण अच्छा है: https://html.spec.whatwg.org/multipage/grouping-content.html... यह name-value pair नहीं, बल्कि name-value group है

    • यह मुझे बिल्कुल नहीं पता था। जिज्ञासा है, क्या आप और को wrap करने वाले element पर `role="listitem"` लगाएंगे? `role="listitem"` शायद पर allowed है, लेकिन जब कई साथ group किए जाते हैं तो यह सही नहीं लगता, और यह भी स्पष्ट नहीं कि इससे की मूल term के रूप में interpretation बिगड़ेगी या नहीं
    • पुराना HTML5 Doctor लेख अब भी मुझे सबसे अच्छा लगता है: https://html5doctor.com/element-index/

  • यहाँ यह लोकप्रिय नहीं होगा, लेकिन semantic HTML इस्तेमाल करने की कोशिश न करने से मेरी ज़िंदगी आसान हो गई है। डिज़ाइन ही बस अच्छा नहीं है इस्तेमाल करने की कोशिश हर बार आख़िर में पछतावा ही बनी, क्योंकि कई स्तर के wrappers चाहिए होते हैं, या sections के बीच separator चाहिए होता है, या icons चाहिए होते हैं, या कई key-value pairs पर फैला heading चाहिए होता है कुछ हद तक flexibility है, लेकिन जिस generalized concept का दावा किया जाता है, उसे वास्तव में संभालने के लिए यह बहुत कम है। हाँ,, `` जैसे matching elements जिनका observable benefit है, उन्हें मैं अब भी इस्तेमाल करता हूँ, लेकिन अगर वह data model पर ठीक से fit नहीं बैठता और सब कुछ override करना पड़ता है, तो यह व्यावहारिक विकल्प नहीं है अगर 99% usage API को bypass करती है, तो यह कहना शायद इतना विवादास्पद नहीं होना चाहिए कि गलती API की है

    • screen reader रोज़ इस्तेमाल करने वाले व्यक्ति के रूप में, मैं पूरी तरह सहमत हूँ W3C अगर ideological semantic purity वाली बकवास छोड़कर ज़्यादा realpolitik तरीके से सोचे, तो सबके लिए बेहतर होगा। API semantically pure है या नहीं, इससे ज़्यादा अहम यह है कि developers क्या करना चाहते हैं, रोकने पर वे कौन से hacks करेंगे, और उस काम को सबके लिए अधिकतम फ़ायदे के साथ कैसे संभव बनाया जाए ARIA live region इसका परफ़ेक्ट उदाहरण है। Developer वास्तव में document.speakText चाहते हैं। उनके पास जो है वह एक अजीब API है जो page के text बदलने पर उसे पढ़कर सुनाती है। इन दोनों के बीच पुल बनाना पड़ता है, और अच्छी implementation में भी यह कठिन और hack जैसा है। फिर भी कम से कम live region वाला तरीका semantically pure HTML तो कहलाएगा
    • तब यह CSS की गलती जैसा लगता है। जैसे display:contents wrappers हटाने देता है, वैसे ही elements को ऐसे group करने का तरीका भी आना चाहिए जैसे उनका कोई common ancestor हो :wrap(dt, dt+dd) {border: solid 1px}
    • HTTP के बारे में भी कुछ ऐसा ही महसूस होता है। यह protocol S3 जैसे resource store के लिए बहुत बढ़िया fit है। GET, PUT, DELETE सब समझ में आते हैं, और HTTP status codes भी इसी use case के लिए बहुत सटीक लगते हैं लेकिन web developer के रूप में, ज़्यादातर लोग resource store नहीं बनाते। वह चीज़ इतनी generic है कि एक बार बनाकर लाखों apps उसे इस्तेमाल कर सकते हैं। जब कोई HTTP के साथ interact करने वाला code लिखता है, तो ज़्यादातर समय वह remote procedure call कर रहा होता है GraphQL, gRPC या कोई और remote procedure call system इस्तेमाल करने पर यह सब पूरी तरह टल जाता है। सब कुछ एक single endpoint पर POST कर दो और एक और abstraction layer जोड़ दो, ताकि application के बहुत specific cases में 4XX/5XX errors लौटाने की ज़रूरत न पड़े RFC authors शायद कुछ ज़्यादा ही आगे बढ़ गए थे। 402 Payment Required, 407 Proxy Authentication Required, 508 Loop Detected ऐसे लगते हैं जैसे किसी specific app या deployment type की ज़रूरतों को web की foundation में ठूँसने की कोशिश की गई हो समझ नहीं आता कि RFC authors की specific ज़रूरतें web की foundation में implement होती हैं, जबकि मेरी ज़रूरतों के लिए मुझे बस कहीं-कहीं मिलने वाले overlap ढूँढकर app-specific चीज़ों को 400 Bad Request या 500 Internal Server Error में ठूँसना पड़े। जब भी किसी web app को बुनियादी से ज़्यादा HTTP status codes का सच में उपयोग करते देखता हूँ, आँखें घूम जाती हैं। वह application layer में होना चाहिए। यह protocol आपके लिए नहीं, बल्कि ज़्यादातर static assets serve करने वाले LAMP stack apps के लिए बना था

  • यह lists के इतिहास का पाठ है। नीचे 1985 का IBM mainframe DCF/GML manual देखें, DL-DT-DD web से पहले से मौजूद था 40 साल से पुराने दस्तावेज़ में सिर्फ़ Definition lists(DL) ही नहीं, बल्कि Glossary lists(GL), Ordered lists(OL), Unordered lists(UL), Simple lists(SL) भी हैं ibm :: 370 :: DCF :: SH35-0050-2 Document Composition Facility Generalized Markup Language Implementation Guide Rel 3 Mar85 https://archive.org/details/bitsavers_ibm370DCFSpositionFaci...

    • GML की जड़ें 1969 तक जाती हैं, और SGML 1970s तक। अंदरूनी तौर पर वे BookMaster नाम की चीज़ इस्तेमाल करते थे, जो HTML का पूर्वज जैसी लगती थी `` की जगह :p., `

  • की जगह:li.` जैसा कुछ था। 1990~1991 के आसपास, जब TBL HTML और HTTP विकसित कर रहे थे, तब HyTime नाम का एक प्रयास भी था, जो hypermedia-केंद्रित SGML application था। HTML ने उसे काफ़ी जल्दी पीछे छोड़ दिया GML/SGML को आगे बढ़ाने वाले Charles Goldfarb के लिए https://en.wikipedia.org/wiki/Charles_Goldfarb देखें, और SGML के लिए https://en.wikipedia.org/wiki/Standard_Generalized_Markup_La... देखें

    • IBM Generalized Markup Language आगे चलकर SGML(Standard Generalized Markup Language) बना, और मेरी समझ है कि CERN में, जहाँ Tim Berners-Lee HTML पर काम कर रहे थे, SGML का काफ़ी इस्तेमाल होता था। HTML उसी से काफ़ी हद तक निकला HTML में दिलचस्प बात यह है कि एक तरह की markup language दशकों तक मौजूद रही, फिर Berners-Lee ने उसमें hyperlink जोड़ दिया
    • अब इसे description list नहीं कहते क्या?

  • दुनिया की पहली website में `` का काफ़ी इस्तेमाल हुआ है https://info.cern.ch/hypertext/WWW/TheProject.html https://info.cern.ch/ असली पहली website के लिए context और दिशा देने वाला एक तरह का landing page है

  • native GUI toolkits सब मर चुके हैं, और अब लोग एक HTML element पर लंबा निबंध लिख सकते हैं। पता नहीं इसे प्रगति कहें या नहीं

  • HTML5 से पहले इसे definition list कहा जाता था, और अब पता चला कि मूल रूप से `` सिर्फ़ terms और definitions वाली glossary दिखाने के लिए था। 10 साल तक मैं इसका नाम ग़लत बोलता रहा

    • b अब “bring attention to” है। कमाल है
    • आप अकेले नहीं हैं। इस हफ़्ते मैंने यह दूसरी बार देखा, और पहली बार लगा था कि यह typo है
    • अभी पता चला कि definition list का नाम बदल गया था
    • मैं यह नहीं देखना चाहता कि HTML5 किस साल standardize हुआ था। बहुत संभव है कि 10 साल से भी ज़्यादा हो चुके हों ;)

  • अच्छा लेख है। बहुत मामूली आपत्ति यह है कि small element subtitle के लिए इस्तेमाल नहीं होना चाहिए, उसके लिए hgroup element इस्तेमाल करना चाहिए small element छोटे अक्षरों वाले supplementary comments को दर्शाता है। छोटे अक्षरों में आम तौर पर disclaimer, caveat, legal restrictions, copyright जैसी चीज़ें आती हैं। कभी-कभी attribution या license requirements पूरी करने के लिए भी इसका उपयोग होता है (https://html.spec.whatwg.org/multipage/text-level-semantics....)

  • screen reader `` को कितना अच्छी तरह support करते हैं, इस पर एक उपयोगी note है: https://adrianroselli.com/2025/01/updated-brief-note-on-desc...

  • DnD ability sheet के आख़िरी example को देखकर सोच रहा हूँ कि क्या `` को nest करना भी वैध है जैसे Actions ... जैसा कुछ किया जा सकता है?

  • मुझे पसंद है। कम से कम पहले तो tables का misuse की तुलना में ज़्यादा होता था, और table markup की असुविधा कई div से भी बदतर है

    • अगर अनावश्यक closing tags छोड़ दें, तो यह इतना असुविधाजनक नहीं है first second what ever मेरे हिसाब से यह किसी भी Markdown table syntax से ज़्यादा simple और साफ़ है
    • सही। लेकिन tables को `` की नकल करने पर मजबूर करना, table misuse की श्रेणी में भी काफ़ी बेहतर था
    • मैंने हमेशा `` को table की single row की तरह सोचा है