क्या आपको पता है कि HTML Table के लिए भी एक API है?

• HTMLTableElement API बहुत पहले से मौजूद है, लेकिन यह HTML table को मैनेज करने वाला built-in interface है जिसका इस्तेमाल बहुत कम होता है
• इस API की मदद से tbody, thead, tfoot, caption, row, cell आदि को सीधे बनाया और access किया जा सकता है, और बदलाव होने पर पूरी table को दोबारा render करने की ज़रूरत नहीं पड़ती
• उदाहरण code में दिखाया गया है कि nested array data को table में कैसे बदला जाए, और insertRow() तथा insertCell() के जरिए row और cell कैसे जोड़े जाएँ
• t.rows[1].cells[1] की तरह index से cell access करना, या insertRow(-1) से आखिरी row जोड़ना जैसी कई तरह की manipulation संभव हैं
• लेखक का कहना है कि इस API में data structure के रूप में table की capabilities बढ़ाने की संभावना है, और form की तरह इसमें events या अतिरिक्त features जोड़े जा सकते हैं

---

HTML table API का अवलोकन

• ज़्यादातर developers DOM methods (createElement आदि) या innerHTML string insertion से table बनाते हैं, लेकिन दूसरा तरीका security risk रखता है
• HTML में पुराना HTMLTableElement API मौजूद है, जिसके जरिए table के body, row, cell, header, footer, caption, summary आदि को संभाला जा सकता है
• यह API पूरी table को दोबारा render किए बिना individual elements को manipulate कर सकता है

Code example: array से table बनाना

• उदाहरण में नीचे दिए गए nested array को table में बदला गया है
  • [['one','two','three'], ['four','five','six']]
• document.createElement('table') से table बनाई जाती है, और हर row (insertRow) व cell (insertCell) को loop के जरिए जोड़ा जाता है
• हर cell की value innerText से सेट की जाती है

Cell access और modification

• बनी हुई table के cells को index-based access से पाया जा सकता है
  • उदाहरण: t.rows[1].cells[1] → <td>five</td>
• row और cell को delete या नया add भी किया जा सकता है
  • उदाहरण: t.insertRow(-1) से आखिर में row जोड़ना
  • t.rows[2].insertCell(0) से नया cell बनाकर innerText = 'foo' से value सेट करना

API की सीमाएँ

• insertRow(-1) जैसी कम intuitive index rules मौजूद हैं
• TH element को सीधे बनाने का कोई तरीका नहीं है, सभी cells TD की तरह handle होते हैं

आगे विस्तार की संभावना

• लेखक बताता है कि table बनाना अभी भी झंझट भरा है, इसलिए इस API की फिर से समीक्षा करके features बढ़ाने की ज़रूरत है
• जैसे HTML form में formData या change event जोड़े गए, वैसे ही table में भी events या advanced features लाए जा सकते हैं
• इससे table को सिर्फ़ layout tool नहीं बल्कि data structure के रूप में भी स्थान मिल सकता है

[sonnet]

तुलनात्मक रूप से कम अनुभव वाले डेवलपर के रूप में, मुझे यह देखकर हैरानी होती है कि कोई लेख शुरू से इस्तेमाल की जा रही API को मानो अभी-अभी "खोज" लिया हो, ऐसे पेश करता है।

[GN⁺]

Hacker News टिप्पणियाँ

• लगता है बहुत से लोगों ने लेख को ठीक से नहीं पढ़ा इस लेख का मुख्य बिंदु `` टैग खुद नहीं, बल्कि table-विशेष DOM interface है उदाहरण के लिए HTMLTableElement.prototype.insertRow() या HTMLTableRowElement.prototype.insertCell() जैसी methods, createElement() या appendChild() से ज़्यादा intuitive हैं लेकिन React, Svelte, Vue जैसी library-आधारित UI में अब ऐसी methods लगभग इस्तेमाल नहीं होतीं HTML syntax की तरह thead, tbody, tfoot को छोड़ा जाए तब भी उनका अपने-आप handle हो जाना दिलचस्प है मैंने पिछले 5 साल में demo scripts में .insertRow, .insertCell, .createTHead, .rows, .cells को सीधे इस्तेमाल किया है code style के हिसाब से मुझे forEach की जगह for इस्तेमाल करना और index argument को छोड़ देना ज़्यादा साफ़ लगता है

  • आजकल frameworks ने बुनियादी DOM manipulation को इतना replace कर दिया है कि ये basics जानने वाले लोग कम होते जा रहे हैं `` टैग पहली बार जोड़े जाने पर C|net का article पढ़ने का समय याद आ गया। लगता है मैं भी अब काफ़ी उम्रदराज़ हो गया हूँ

• करीब आधा साल पहले MDN docs देखकर या AI की recommendation पर मैंने यह API इस्तेमाल किया था rows और cells properties keyboard navigation implement करने में बहुत सुविधाजनक थीं इससे जुड़ा example ClickHouse code में देखा जा सकता है

  • आज की web में सबसे दुख की बात है div से table बनाने वाले लोग न sorting ठीक से होती है, और खासकर M365 Admin जैसे मामलों में table implementation बेहद खराब होती है

• यह buttons पर हुई चर्चा(पिछला thread) जैसा ही संदर्भ है करीब 10~15 साल पहले से सब कुछ `` में बदलने लगा, और semantic markup की जगह HTML को UI toolbox की तरह इस्तेमाल किया जाने लगा

  • क्योंकि DOM मूल रूप से semantic document नहीं, बल्कि rendering target की तरह इस्तेमाल होता है semantic HTML एक अच्छा विचार है, लेकिन व्यवहार में उससे बहुत उम्मीद करना मुश्किल है ऊपर से semantic elements की default styling होती है, इसलिए developers neutral को पसंद करने लगते हैं सच कहूँ तो और `` को अलग-अलग रखना भी मुझे design mistake लगता है
  • मैं 20 साल से ज़्यादा समय से HTML इस्तेमाल कर रहा हूँ, लेकिन मेरे अनुभव में ज़्यादातर लोग अब भी meaningful tags का ठीक इस्तेमाल करते हैं हाँ, कुछ लोग सब कुछ div से करते हैं, लेकिन button जैसे मामलों में आमतौर पर सही markup ही लिखा जाता है
  • मुझे लगता है यह बदलाव अपरिहार्य था web का ज़्यादातर content marketing-केंद्रित है, इसलिए कंपनियाँ चाहती हैं कि चीज़ें बिल्कुल उनकी पसंद के रूप में दिखें अगर technical documentation के लिए कोई अलग DocBook web होता, जहाँ user अपनी styling खुद apply कर सकता, तो वह दिलचस्प होता

• Stable Diffusion image comparison tool बनाते समय मैंने यह API इस्तेमाल की थी rows और columns बहुत ज़्यादा थे, इसलिए table को बार-बार recreate करना पड़ता था, लेकिन string से एक बार में बनाने की तुलना में DOM updates धीमे थे शायद इसलिए कि हर API call तुरंत DOM को update कर देती है

• इसमें कहा गया था, “पूरी table को फिर से render करने की ज़रूरत नहीं पड़ती”, लेकिन असल में standard DOM methods भी पहले से ऐसे ही काम करती हैं फिर भी उबाऊ DOM traversal कम हो जाता है, यह काफ़ी बढ़िया बात है

  • WebKit code देखने पर लगा कि अंदरूनी तौर पर वही logic चलती है, इसलिए performance difference लगभग नहीं है

• HTML form API को भी फिर से rediscover करने की ज़रूरत है

• table की समस्या data भरने में नहीं, बल्कि search·sorting·filtering features का बिल्कुल न होना है

  • यह किससे तुलना करके कहा जा रहा है, जानना चाहूँगा मुझे नहीं लगता कि table में ऐसे features implement न किए जा सकें

• “यह API abandon हो गई” वाली बात समझ नहीं आती मैं आज भी HTML tables बनाते समय इसे अक्सर इस्तेमाल करता हूँ

  • ‘Abandonware’ शब्द मूल रूप से license context में इस्तेमाल होता है, इसलिए यहाँ यह कुछ ज़्यादा बढ़ा-चढ़ाकर किया गया title है शायद लेखक कहना चाहता था कि यह API विस्तार की गुंजाइश वाला पुराना क्षेत्र है forms API की तरह tables में भी sorting·filtering जैसी features जोड़ी जा सकती हैं
  • आजकल ज़्यादातर लोग React या Svelte जैसे declarative UI frameworks इस्तेमाल करते हैं, इसलिए ऐसे imperative DOM API धीरे-धीरे niche बनते जा रहे हैं
  • एक वाक्य में कहें तो, अभी React का दौर है

• example code दिलचस्प है, लेकिन variable names को बहुत छोटा कर देने से readability गिर जाती है b, t, r, c की जगह meaningful names इस्तेमाल करना बेहतर है

  • ऐसी चर्चा आखिरकार bike-shedding की तरह मामूली हिस्सों पर केंद्रित हो जाती है
  • छोटे scope में छोटे variable names इस्तेमाल करना स्वाभाविक है
  • फिर भी एक-अक्षर वाले variable names मुझे गलत optimization लगते हैं Haskell इस्तेमाल करने वाले के तौर पर मैं इससे खास तौर पर सहमत हूँ
  • छोटे नाम से ज़्यादा (ri, i) जैसी index mixing ज़्यादा उलझाती है मिलती-जुलती भूमिका वाले variables की length भी एक जैसी रखना बेहतर है
  • let b = document.body; जैसी line पढ़ना खास तौर पर मुश्किल है कुछ bytes बचाने के चक्कर में सिर्फ cognitive load बढ़ता है