1 पॉइंट द्वारा GN⁺ 1 시간 전 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • HTML सूचियों का चयन दृश्य रूप के बजाय अर्थ और इंटरैक्शन के तरीके के आधार पर करना चाहिए, और इन्हें control, ordered, description, menu, तथा unordered सूचियों में बाँटा जाता है
  • स्थिर विकल्पों के लिए <select>/<option> सही हैं, जबकि सुझाव-आधारित इनपुट के लिए <datalist> उपयुक्त है; साथ ही multiple, optgroup, size, और value के व्यवहार में अंतर समझना चाहिए
  • <ol> उन प्रक्रियाओं, घटनाओं और निरंतरताओं के लिए है जिनमें क्रम बदलने पर अर्थ बदल जाता है, और reversed केवल नंबरिंग उलटता है, वास्तविक आइटम क्रम नहीं
  • <dl> HTML5 में definition list से आगे बढ़कर description list बन गया है, और term-value, metadata, तथा JSON debugging जैसे key-value जोड़ों के लिए उपयुक्त है
  • <menu> tool buttons जैसी command सूचियों के लिए है, इसका अर्थ और allowed content nav से अलग है, और बाकी सामान्य सूचियों के लिए <ul> इस्तेमाल होता है

कंट्रोल सूची: <select>/<option> और <datalist>

  • फ़ॉर्म में भी उपयोगकर्ता के साथ इंटरैक्ट करने वाली सूचियाँ बनाई जा सकती हैं
  • स्थिर विकल्पों के लिए <select> और <option>

    • अगर उपयोगकर्ता को केवल सूची के भीतर मौजूद आइटमों में से चुनना हो, तो <select> और <option> का उपयोग करें
    • भाषा सूची के उदाहरण में Select a Language, English, French, Spanish, Portuguese जैसे <option> को <select name="languages"> के भीतर रखा जाता है
    • डिफ़ॉल्ट <select> एक समय में ठीक एक विकल्प चुनने देता है
    • कई आइटम चुनने के लिए multiple attribute जोड़ें
      • multiple इस्तेमाल करने पर सूची का प्रदर्शन बदल जाता है और सभी विकल्प दिखते हैं; उपयोगकर्ता Shift या Cmd + click से कई आइटम चुन सकता है
      • वास्तविक select और option उपयोग करने पर role="listbox" वाले तत्व पर aria-multiselectable अलग से लगाने की ज़रूरत नहीं होती, क्योंकि browser की default semantics इसे संभाल लेती है
  • संबंधित विकल्पों को <optgroup> से समूहित करें

    • अगर भाषाओं को language family के आधार पर समूहित करना हो, तो <optgroup> से विकल्प सूची को समूहित करें
    • उदाहरण में label वाले Germanic, Romance, Celtic नाम के <optgroup> बनाए जाते हैं और हर समूह में English, French, Spanish, Portuguese, Irish, Welsh रखे जाते हैं
    • अगर किसी खास sub-group को selectable नहीं बनाना हो, तो उस <optgroup> पर disabled attribute जोड़ें
    • उदाहरण में Celtic समूह पर disabled लगाकर Irish, Welsh वाला समूह निष्क्रिय किया गया है
  • default HTML features से बेहतर बनाना

    • समूहों के बीच दृश्य विभाजन चाहिए तो <select> के भीतर अनुमति प्राप्त <hr> का उपयोग किया जा सकता है
    • size attribute एक बार में दिखने वाले आइटमों की संख्या नियंत्रित करता है, इसलिए लंबी सूचियों में उपयोगी है
    • size और optgroup साथ उपयोग करने पर group labels भी जगह घेरते हैं
    • उदाहरण में <select name="languages" size="4" multiple> में Germanic, Romance, Celtic, Afroasiatic समूहों के साथ उनके बीच <hr /> रखा गया है, और Hebrew, Arabic भी शामिल हैं

सुझाव सूची: <datalist>

  • अगर उपयोगकर्ता को सूची से ही चुनना अनिवार्य नहीं है, बल्कि सूची केवल सुझाव देती है, तो <datalist> का उपयोग करें
  • <datalist> दो चरणों में जोड़ा जाता है
    • <datalist> बनाकर उसे id दें
    • संबंधित <input> के list attribute में वही id मान डालें
  • भाषा सुझाव के उदाहरण में <datalist id="languages"> के भीतर English, French, Spanish, Portuguese, Irish, Welsh, Hebrew, Arabic विकल्प रखे जाते हैं, और <input name="language" list="languages"> से इनपुट फ़ील्ड को जोड़ा जाता है
  • <option value> का व्यवहार

    • <option> का default value उसके भीतर का text होता है, और अगर value attribute मौजूद हो तो वही default को override कर देता है, जबकि text label की तरह काम करता है
    • <select> में उपयोगकर्ता को सिर्फ text दिखता है, इसलिए यह बड़ी समस्या नहीं होती; लेकिन <datalist> में उपयोगकर्ता label देखकर चुनता है और input box में value भर जाता है, जिससे भ्रम हो सकता है
    • उदाहरण में <option value="cy">Welsh</option> चुनने पर उपयोगकर्ता Welsh देखता है, लेकिन input में cy भर जाता है
    • <datalist> इस्तेमाल करते समय यह मानकर चलना चाहिए कि जो डाला जाएगा वह label नहीं बल्कि value है
  • कई input types के साथ संयोजन

    • <datalist> सिर्फ text options के लिए नहीं है; इसे दूसरे input types के साथ भी इस्तेमाल किया जा सकता है
    • सप्ताह चयन के उदाहरण में <input type="week" name="week" id="camp-week" min="2026-W2" max="2026-W51" list="preferred-weeks" /> को <datalist id="preferred-weeks"> से जोड़ा जाता है
    • सुझाए गए सप्ताह 2026-W22, 2026-W23, 2026-W24, 2026-W25 हैं
  • <input type="range"> के साथ संयोजन

    • <datalist> सिर्फ string values तक सीमित नहीं है; यह संख्याओं के साथ भी काम करता है, इसलिए इसे range input के साथ जोड़कर range के ऊपर label वाले बिंदु बनाए जा सकते हैं
    • tip प्रतिशत input के उदाहरण में <input type="range" name="tips" id="tips" min="0" max="50" step="1" list="recommended-tips" /> को <datalist id="recommended-tips"> से जोड़ा जाता है और 10%, 18%, 30%, 45% labels दिए जाते हैं
    • Chrome-आधारित browsers में @supports (x: attr(x type(percentage))) से attr() का label मान पढ़ा जाता है, type() से value को percentage घोषित किया जाता है, और options को position: absolute से रखा जाता है
    • Firefox के लिए @supports not (x: attr(x type(percentage))) का उपयोग होता है, और values ::before से दिखाई जाती हैं
    • यह तरीका इस बात की गारंटी नहीं देता कि सभी browsers एक ही तरह काम करेंगे या स्क्रीन पर बिल्कुल एक जैसा दिखेंगे

क्रमबद्ध सूची: <ol>

  • जिन आइटमों को किसी निश्चित क्रम में पढ़ा जाना चाहिए, उनके लिए <ol> का उपयोग करें
  • आधार यह नहीं है कि आइटम के बगल में नंबर दिखना चाहिए या नहीं, बल्कि यह है कि आइटमों का क्रम बदलने पर सूची का अर्थ बदलता है या नहीं
  • <ol> के लिए उपयुक्त collections में algorithms, घटना-श्रृंखलाएँ, बढ़ती या घटती निरंतरता पर स्थित आइटम, recipes, और alphabetical lists शामिल हैं
  • banana bread recipe के उदाहरण में oven को preheat करना, pan पर grease लगाना, सामग्री मिलाना, batter डालना, 60 मिनट bake करना या toothpick साफ़ निकलने तक bake करना, और wire rack पर ठंडा करना—इन सबको <ol> से दिखाया गया है
  • alphabetical सामग्री सूची भी alphabet नाम की निरंतरता का पालन करती है, इसलिए वह भी <ol> के अंतर्गत आती है, और baking soda, bananas, brown sugar, butter, eggs, flour, salt इसी क्रम में रखे जाते हैं
  • क्रमबद्ध और अक्रमबद्ध सूचियों का nesting

    • अच्छी तरह संरचित ordered list को browser rendering देखे बिना भी पढ़कर समझा जा सकता है कि क्या किस क्रम में होना चाहिए
    • recipe उदाहरण में ऊपरी स्तर के चरणों के लिए <ol> उपयोग होता है, और चरण के भीतर जहाँ क्रम महत्वपूर्ण नहीं होता वहाँ <ul>, फिर जहाँ उप-चरणों का क्रम महत्वपूर्ण हो वहाँ <ol> nested होता है
    • संरचना Prepare, Mix, Pour, Bake, Cool के top-level क्रम को बनाए रखती है, जबकि Prepare और Bake के भीतर parallel आइटम <ul> से, और MixCool के भीतर प्रक्रियात्मक sub-steps <ol> से व्यक्त होते हैं
  • reversed

    • reversed attribute नंबरिंग के क्रम को ascending से descending में बदल देता है
    • यह वास्तविक सूची आइटमों का क्रम नहीं बदलता
    • इसे most to least की तरह अधिक से कम दिखाने वाली सामग्री और मात्रा सूची में इस्तेमाल किया जा सकता है
    • उदाहरण में <ol reversed> के भीतर eggs (2), flour (2 cups), bananas (2) (mashed), brown sugar (¾ cup), butter (½ cup), baking soda (1 teaspoon), salt (¼ teaspoon) रखे गए हैं
  • JavaScript से वास्तविक आइटम क्रम उलटना

    • अगर सूची को वास्तव में उलटना हो, तो JavaScript से li children को reverse order में फिर से व्यवस्थित करके reversed attribute toggle किया जा सकता है
    • उदाहरण function list.querySelectorAll('li') के परिणाम को array में बदलकर .reverse() करता है, फिर list.innerHTML = '' से खाली करता है और list.append(...children) से दोबारा जोड़ता है
    • अंत में list.toggleAttribute('reversed') कॉल करता है
    • उदाहरण event orderedList.addEventListener('dblclick', (evt) => { reverseList(orderedList) }) के जरिए double-click पर reverse चलाता है
  • start

    • start attribute तब उपयोगी होता है जब एक बहुत बड़ी सूची की जगह कई ordered lists में बाँटना हो, लेकिन नंबरिंग की निरंतरता बनाए रखनी हो
    • banana bread recipe में Prepare को ul रखा गया है, जबकि Mix को <ol start=2>, Pour को <ol start=5>, और Cool को <ol start=7> की तरह आगे बढ़ते step numbers दिए गए हैं
    • बीच में 6: Bake जैसा कोई section unordered list के रूप में व्यक्त हो, तब भी बाद के Cool के ol को start=7 से शुरू करके पूरे process की numbering flow बनाए रखी जा सकती है

विवरण सूची: <dl>, <dt>, <dd>

  • विवरण सूची (description list) ऐसी सूची है जो हर चीज़ को ज़बरदस्ती ol या ul में ठूँसने की ज़रूरत खत्म करती है
  • HTML 4 की definition list

    • HTML 4 में इसे description list नहीं बल्कि definition list कहा जाता था, और इसका उपयोग definitions देने जैसे अधिक सीमित उद्देश्य के लिए था
    • इसकी संरचना में परिभाषित किया जाने वाला term <dt> और उसका definition content <dd> होता था; semantic रूप से और सही उपयोग के लिए परिभाषित term को <dfn> में wrap किया जाता था
    • उदाहरण में throw, yeet को एक ही definition से जोड़ा गया है, और no cap, bet के लिए अलग-अलग definitions दी गई हैं
      <dl>
        <dt><dfn>throw</dfn></dt>
        <dt><dfn>yeet</dfn></dt>
        <dd>Verb. To discard at a high velocity</dd>
        <dt><dfn>no cap</dfn></dt>
        <dd>Interjection. Expresses authenticity and truthfulness, sometimes surprise.</dd>
        <dt><dfn>bet</dfn></dt>
        <dd>Interjection. Expresses agreement and affirmation.</dd>
      </dl>
    
  • HTML5 में विस्तृत अर्थ

    • HTML5 में यह केवल definitions तक सीमित नहीं रहा, बल्कि description list बन गया, और जहाँ भी “terms और values का समूह” हो वहाँ इसका उपयोग किया जा सकता है
    • HTML5 में संबंधित <dt> और <dd> को समूहित करने के लिए non-semantic wrapper <div> की अनुमति है
    • browser engine उदाहरण में Chrome, Opera, Brave, Edge को Blink-based browsers के अंतर्गत और Firefox, Tor, Librewolf को Gecko-based browsers के अंतर्गत समूहित किया गया है
      <dl>
        <div class="dl-item">
          <dt>Chrome</dt>
          <dt>Opera</dt>
          <dt>Brave</dt>
          <dt>Edge</dt>
          <dd>Blink-based browsers</dd>
        </div>
        <div class="dl-item">
          <dt>Firefox</dt>
          <dt>Tor</dt>
          <dt>Librewolf</dt>
          <dd>Gecko-based browsers</dd>
        </div>
      </dl>
    
  • metadata और JSON debugging

    • अगर सामग्री facts और labels की एक श्रृंखला है, तो metadata दिखाने के लिए description list उपयुक्त है
    • user profile भी <dl> में रखा जा सकता है; उदाहरण में First Frank, Last Taylor, Age 44, Job Writer, Handle Paceaux को <dt> और <dd> जोड़ों के रूप में व्यक्त किया गया है
    • single-page application में JSON debugging के लिए भी description list उपयोगी हो सकती है
    • DebugJson उदाहरण में object के हर key, value को Object.entries(obj) से iterate करके key को <dt><var>...</var></dt> और value को <dd><code>...</code></dd> के रूप में render किया जाता है
    • अगर value object है और array नहीं है, तो DebugJson.createDl(value) को फिर से call करके nested <dl> बनाया जाता है; अन्य values के लिए value.toString() को <code> के भीतर रखा जाता है
      const debugJson = new DebugJson({foo: 'bar', arr: ['a', 'b'], car: 1}, '.container')
      debugJson.render();
    
    • description list key-value pairs की ज़रूरतों पर व्यापक रूप से फिट बैठती है

मेनू: <menu>

  • menu element commands की सूची को दर्शाता है, और यह content rendering की तुलना में interactive web के अधिक करीब है
  • menu उन button सूचियों के लिए उपयुक्त है जो rich text editor के text-modification controls जैसे “tools” का काम करती हैं
  • rich text editor उदाहरण में Strong, Emphasize, Strike buttons को menu के भीतर li में रखा गया है
  <menu>
    <li><button onclick="strong()">Strong</button></li>
    <li><button onclick="emphasize()">Emphasize</button></li>
    <li><button onclick="strike()">Strike</button></li>
  </menu>
  • HTML specification के अनुसार यह toolbar उपयोग का मामला है, और interactive pages में जहाँ tool buttons हों वहाँ menu आने की संभावना अधिक है
  • video controls का उदाहरण भी menu में आता है, जहाँ button पर commandfor="vid-123" और command="--play", --mute, --fullscreen दिए गए हैं
  <div class="player player--video">
    <video source="whatever.mp4" id="vid-123"></video>
    <menu>
      <li><button commandfor="vid-123" command="--play">Play</button></li>
      <li><button commandfor="vid-123" command="--mute">Mute</button></li>
      <li><button commandfor="vid-123" command="--fullscreen">Fullscreen</button></li>
    </menu>
  </div>
  • menu उपयोग करने पर unordered list में aria-role="menu" अलग से जोड़ने की ज़रूरत नहीं होती
  • यह मत मानिए कि li केवल दो containers में ही जाता है

    • अगर navigation के list items को सामान्य सूची जैसा नहीं दिखाना है, तो menu li पर भी वही treatment लागू करना होगा
    • stylesheet के ऊपर nav li के साथ menu li को भी शामिल करके list-style-type, text-indent, margin reset किए जाते हैं
      nav li,
      menu li {
          list-style-type: none;
          text-indent: 0;
          margin: 0;
      }
    
  • <nav> और <menu> अलग हैं

    • nav, links वाला menu भर नहीं है; दोनों का अर्थ और allowed content अलग है
    • nav एक sectioning element है, जिसका अर्थ है कि यह उपयोगकर्ता को “कहीं जाने से संबंधित कई आइटम” देता है
    • nav में <p>, <h1-6> जैसे paragraphs और headings, तथा <ul>, <ol>, <menu> जैसी सूचियाँ हो सकती हैं
    • menu एक list element है, जिसका अर्थ है कि यह उपयोगकर्ता को “क्या किया जा सकता है” की सूची देता है, और इसमें केवल list items <li> की अनुमति है
    • menu और nav एक-दूसरे के विकल्प नहीं हैं; menu, nav के भीतर आ सकता है, लेकिन nav, menu के भीतर नहीं आ सकता

अक्रमबद्ध सूची: <ul>

  • ul ऐसी catch-all list है जो बाकी उन सूची-ज़रूरतों को संभालती है जिन्हें अन्य list types या nav से हल नहीं किया जा सकता
  • पुराने HTML में ordered list और unordered list का अंतर संख्या बनाम bullet जैसे दृश्य अंतर के अधिक करीब था
  • अब accessibility, screen readers, और search engine optimization को ध्यान में रखते हुए दृश्य रूप से अधिक महत्वपूर्ण बात यह है कि क्या क्रम अर्थ रखता है
  • band members की सूची में क्रम महत्वपूर्ण नहीं है, इसलिए वह ul के अंतर्गत आती है
  <h3>Beatles</h3>
  <ul>
    <li>John Lennon</li>
    <li>Paul McCartney</li>
    <li>Ringo Star</li>
    <li>George Harrison</li>
  </ul>
  • band names की सूची को भी unordered list के रूप में व्यक्त किया जा सकता है
  <ul>
    <li>Beatles</li>
    <li>Rolling Stones</li>
    <li>Van Halen</li>
    <li>Foo Fighters</li>
  </ul>

1 टिप्पणियां

 
GN⁺ 1 시간 전
Hacker News टिप्पणियाँ
  • सिर्फ उदाहरण टेस्ट करके भी लगता है कि datalist Mobile Safari में ठीक से काम नहीं करता
    अगर इतने बड़े मार्केट में compatibility समस्या है, तो व्यावहारिक रूप से ऐसे scenarios बहुत कम बचते हैं जहाँ इसका इस्तेमाल करना वाजिब लगे

    • यह ऐसी कड़वी सच्चाई वाली जानकारी है जो चाहिए तो नहीं थी, लेकिन ज़रूरी थी

      10 साल से भी पहले मैंने एक प्रोजेक्ट पर काम किया था जिसमें UI में काफ़ी aggressive input suggestion widget था, और तब हमने jQuery plugin इस्तेमाल किया था
      वह frontend का सबसे complex हिस्सा था, और सच कहूँ तो उसी प्रोजेक्ट में jQuery इस्तेमाल करने की मुख्य वजह भी वही थी

      यह लेख पढ़ते हुए लगा कि उस frontend को हल्के JS-minimized version में फिर से implement करना तो बहुत आसान होगा, लेकिन जब तक आप अपना environment जस का तस user के device पर ship नहीं करते, हक़ीक़त ऐसी नहीं होती
      फिर भी आजकल HTML spec में शामिल features काफ़ी प्रभावशाली हैं
      हाई स्कूल में XHTML पढ़ने के बाद से मैंने spec changes लगभग follow ही नहीं किए, तो कभी-कभी जाकर देखना चाहिए कि क्या बदला है
      बस browser compatibility तब भी सिरदर्द थी और आज भी है

    • datalist उदाहरण मेरे iPhone पर तो पक्का काम करता है
      यह native iOS keyboard के ऊपर वाले autocomplete suggestions area में integrate हो जाता है
      लेकिन सारे suggestions को browse करने का कोई तरीका नहीं है, और शायद datalist का intended use भी यही नहीं है

      लेकिन group का disabled attribute निश्चित रूप से काम नहीं करता

    • Android के Firefox में भी यह काम नहीं करता

    • बहुत पहले अपनी पहली नौकरी में Firefox में datalist काम नहीं करता था, और इसी वजह से Firefox को supported browsers की सूची से निकाल दिया गया था

      Chrome के अलावा दूसरे browsers को support करना हो तो यह feature लंबे समय से समस्या बना हुआ है

    • iOS पर GBoard के साथ यह ठीक से काम नहीं करता

  • optgroup में disabled attribute जोड़कर कुछ options को चुनने लायक न बनाने वाला उदाहरण Mobile Safari में टूटा हुआ लगता है
    व्यवहार में यह disable नहीं होता, और disabled items भी फिर भी चुने जा सकते हैं

    • नई Safari में यह काम करना चाहिए, इसलिए यह पूरी तरह टूटा नहीं बल्कि कुछ अजीब स्थिति जैसा लगता है

      https://caniuse.com/mdn-html_elements_optgroup_disabled

      यह Safari bug हो सकता है

    • बुनियादी चीज़ों से आगे native HTML का इस्तेमाल कठिन होने की यही वजह है
      आप इतना पढ़-समझ लें कि आत्मविश्वास से ऐसा लेख लिख सकें, फिर भी comments में अलग-अलग browser और device combinations के अजीब व्यवहार, limitations और lack of support की जानकारी आ ही जाती है

      div का अति-इस्तेमाल शायद दूसरी दिशा में बहुत दूर चला गया विकल्प हो, लेकिन कम से कम उसके odd behaviors और limitations काफ़ी consistent और दिखाई देने वाले होते हैं
      क्योंकि वे या तो मेरे लिखे हुए होते हैं या framework के बनाए हुए, और ज़्यादा लगातार तरीके से fit बैठते हैं

  • मज़ेदार और व्यापक लेख है

    अफ़सोस की बात है कि आजकल बहुत से डेवलपर्स HTML सीखे बिना सीधे React में चले जाते हैं, और अब LLMs के साथ तो यह संभावना और बढ़ गई है कि वे HTML बिल्कुल न सीखें

    इसलिए जहाँ simple HTML काफ़ी होता, वहाँ भी वे React components ढूँढने लगते हैं

    • मुझे लगता है यह ठीक है

      जब पहली बार XML इस्तेमाल करना पड़ा था, तब XML spec सीखनी पड़ती थी और output हाथ से बनाना पड़ता था
      वह दौर था जब serialization libraries लगभग थीं ही नहीं
      बाद में मैंने जूनियर पीढ़ियों को XML, और फिर JSON को interchange format की तरह इस्तेमाल करते देखा बिना उन्हें पूरी तरह सीखे, और कोई बड़ी समस्या नहीं हुई

      AJAX भी hot new tech से उस stage तक गया जहाँ लोगों को उसके acronym का मतलब भी नहीं पता था, और अब तो ज़्यादातर लोग वह term भी पहचानते नहीं
      AJAX मरा नहीं; वह इतना आम हो गया कि उसके लिए अलग शब्द की ज़रूरत ही नहीं रही

    • मेरी समस्या यह है कि 20 साल पहले मैंने HTML बहुत गहराई से सीखा था, और उसके बाद यह कैसे बदला और बेहतर हुआ, यह बस इत्तफ़ाक़ से थोड़ा-थोड़ा ही पता चला
      CSS के साथ तो यह और भी ज़्यादा सच है

    • ईमानदारी से कहूँ तो HTML झंझट वाला है

      उदाहरण के लिए control के किसी हिस्से को style करने का HTML-style तरीका pseudo-classes का उपयोग है, लेकिन कभी-कभी selectors हर browser में अलग होते हैं
      तब browser-specific testing करनी पड़ती है, क्योंकि यह पता ही नहीं होता कि चीज़ वास्तव में सही चलेगी या नहीं

      React न सिर्फ़ आसान है, बल्कि ज़्यादा भरोसेमंद भी है
      React और divs से बनाओ तो उम्मीद की जा सकती है कि वह सभी browsers में एक जैसा काम करेगा

  • सामग्री अच्छी है, लेकिन datalist से बहुत ज़्यादा उम्मीद नहीं रखनी चाहिए
    वास्तव में उपयोगी होने के लिए इसमें integration points कम हैं, इसलिए छोटे prototypes से आगे के उपयोग के लिए यह उपयुक्त नहीं है

    • मैंने autocomplete suggestions के लिए datalist इस्तेमाल किया है और वह बहुत अच्छा चला
    • लगता है मैंने कभी datalist से combobox बनाने की कोशिश की थी, लेकिन वह सफल नहीं हुई
  • सोच रहा हूँ कि क्या HTML linters सच में ऐसे differences पहचानने में मदद करते हैं
    यह भी जानना है कि क्या कोई linter इस तरह की semantic tag selection enforce कर सकता है

    • semantic tags को enforce करने का विचार मुझे ज़्यादा समझ नहीं आता
      HTML का मकसद सबसे पहले authors को creative freedom देना है, और किसी एक tag को दूसरे पर force करना मुझे सही नहीं लगता
      accessibility अहम है, लेकिन constraints पहले ही काफ़ी हैं

    • मुझे जो सबसे क़रीबी चीज़ पता है वह यह है: https://github.com/kristoff-it/superhtml#diagnostics

      SuperHTML सिर्फ syntax ही नहीं, element nesting और attribute values भी validate करता है
      HTML spec को validation code में पूरी तरह implement करने वाला कोई और language server नहीं है

  • आज यह नई बात पता चली
    सोच रहा हूँ कि और frameworks इसका फ़ायदा क्यों नहीं उठाते

    • user experience के नज़रिए से यह एक सामान्य list जैसा ही है
      अगर code समझने में मदद मिले तो इसका इस्तेमाल कर सकते हैं, लेकिन browser की accessibility tree और बाकी सभी पहलुओं में यह बस एक unordered list ही है

      अगर बताना है कि कोई चीज़ actions की list है, तो ARIA attributes जोड़ने पड़ेंगे
      लेख में role=menu का ज़िक्र है, लेकिन सिर्फ़ वही काफ़ी नहीं; हर item को menuitem role भी चाहिए
      WAI Authoring Practices Guide roles और interaction expectations समझाती है, लेकिन code examples को ज्यों का त्यों copy मत कीजिए, और खासकर navigation menus में यह role इस्तेमाल नहीं करना चाहिए

      https://www.w3.org/WAI/ARIA/apg/patterns/menubar/

    • समझदार लोग मुश्किल HTML नहीं सीखते, बस कई div लगाकर काम चला लेते हैं

    • आजकल HTML में कई दिलचस्प features हैं

      मुझे लोगों से पूछना अच्छा लगता है कि वे किस element के बारे में क्या सोचते हैं कि वह क्या करता है
      मैं भी शुरू में लगभग कुछ भी सही नहीं बता पाया था

  • कई साल frontend lead के रूप में काम करने के बाद भी यहाँ बहुत सी उपयोगी बातें थीं जो मुझे नहीं पता थीं
    लगता है हम अपनी कंपनी में भी इसे आज़माना शुरू करेंगे

  • काश designers को default datalist appearance पसंद आ जाती

    • मेरे अनुभव में styling customization की कमी native HTML features इस्तेमाल करने की सबसे बड़ी बाधा है
  • ब्लॉग पोस्ट बहुत अच्छी है, लेकिन ब्लॉग की सभी posts की सूची एक साथ देखने का कोई तरीका मुझे मिल नहीं रहा

    https://blog.frankmtaylor.com/archive काम नहीं करता

    https://blog.frankmtaylor.com/archives भी नहीं

    https://blog.frankmtaylor.com/posts भी नहीं

    https://blog.frankmtaylor.com/all भी नहीं है

    https://blog.frankmtaylor.com/blog भी नहीं

    बहुत से लोगों के पास 10,000 से ज़्यादा bookmarks होते हैं, इसलिए अगर बिना description या पूरी पोस्ट के अब तक लिखी गई सारी posts की एक single list page मिल जाए तो सच में सुविधाजनक होगा

    • क्या आप sitemap की बात कर रहे हैं?
      ज़्यादातर blogs में सभी posts की सूची वाला sitemap.xml होता है

      और यह भी जानना चाहूँगा कि आप 235 posts को पूरा browse क्यों करना चाहते हैं