HTML पर दांव लगाना

 (catskull.net)
1 पॉइंट द्वारा GN⁺ 2023-08-03 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • बड़े language model-आधारित AI के फैलने के साथ, इंसानों को दिखने वाली स्क्रीन जितना ही मशीन द्वारा पढ़े जा सकने वाले semantic HTML का मूल्य भी बढ़ रहा है
  • बड़े social media के closed garden डेटा पोर्टेबिलिटी और interoperability को रोकते हैं, और fediverse·Threads·Bluesky जैसे distributed प्रयासों में भी आम उपयोगकर्ताओं को खींचने की प्रेरणा कमज़ोर है
  • आधुनिक HTML में <details>, <dialog>, और तरह-तरह के <input> जैसे वेब ऐप्स के लिए ज़रूरी मूलभूत UI elements पहले से ही काफी हद तक मौजूद हैं
  • browser की default styling और reader mode का उपयोग करने से अत्यधिक CSS·JavaScript निर्भरता कम की जा सकती है, और सही tags machine readability तथा mobile input अनुभव को बेहतर बनाते हैं
  • ऐसे दौर में जब RSS अब भी ज़िंदा है और ChatGPT जैसे interfaces डेटा तक पहुँचने के तरीके के रूप में उभर रहे हैं, विज्ञापन-केंद्रित interfaces की तुलना में structured HTML अधिक व्यावहारिक आधार बन सकता है

वेब के बुनियादी डेटा इंटरफ़ेस के रूप में HTML

  • बड़े language model-आधारित AI के आगमन ने semantic HTML की अहमियत को फिर से बढ़ा दिया है
  • इंटरनेट का मूल काम लोगों को दुनिया के साथ इंटरैक्ट करने के लिए ज़रूरी डेटा पहुँचाना है, लेकिन HTML/CSS/JavaScript की स्वतंत्रता का एक दूसरा पहलू यह भी है कि यह डेटा एक्सेस को सीमित कर सकती है
  • बड़ी tech कंपनियों के social media, खुले और सुलभ data formats तथा APIs की बजाय उपयोगकर्ताओं को closed platforms के भीतर बाँधकर रखते हैं
    • platforms के बीच interoperability व्यावहारिक रूप से कठिन हो गई है
    • कंपनियाँ आसान data portability से बचती हैं, जिससे समस्या और जटिल हो जाती है
  • हाल के social media अस्थिरता के दौर ने fediverse जैसे distributed platforms में रुचि फिर बढ़ाई है
    • Meta का Threads और Jack Dorsey द्वारा बनाया गया Bluesky, बड़े fediverse के साथ interoperability को अपनी खासियत के रूप में पेश करते हैं
    • लेकिन आम उपयोगकर्ता अक्सर सिर्फ इसी वजह से नया social media नहीं चुनते
  • अब समय है कि पहले से प्रमाणित समाधान HTML को फिर से देखा जाए
    • पहले browser में HTML content को ठीक-ठाक दिखाने के लिए बहुत CSS का इस्तेमाल करना पड़ता था
    • अब कई modern HTML elements जुड़ चुके हैं, जो आधुनिक web applications के लिए ज़रूरी अधिकांश UI elements उपलब्ध कराते हैं
    • reader mode styling पर लगाए गए समय को बेअसर कर सकता है, और इसे सकारात्मक रूप में देखा जा सकता है
  • सही tags मशीन के लिए आसानी से पढ़े जा सकने वाला format देते हैं
    • यह सिर्फ design समय बचाने से भी अधिक मज़बूत कारण है कि modern HTML को अपनाया जाए
    • RSS अब भी ज़िंदा है
    • ChatGPT जैसे interfaces भविष्य में इंसानों द्वारा डेटा एक्सेस करने का तरीका बन सकते हैं

उपयोगी या नए नज़रिए से देखने लायक HTML elements

  • MDN की HTML elements की पूरी सूची देखना उपयोगी है
    • नीचे दिए गए उदाहरणों में अलग styling के बिना सिर्फ browser की default styling का उपयोग किया गया है
    • browser के अनुसार उनका रूप काफ़ी अलग हो सकता है, या वे बिल्कुल समर्थित न हों
  • <abbr>: abbreviation को घेरने वाला element
    • styling लगाकर इसे उभारा जा सकता है
    • मुख्यतः machine parsing के लिए उपयोगी है
  • <datalist>: input candidates की सूची देने वाला element
    • typeahead जैसा दिखने वाला UI बनाया जा सकता है
    • इसमें built-in validation नहीं दिखती
    • Safari में option tag को बंद करना ज़रूरी है, नहीं तो यह काम नहीं करता
  • <details>: expand/collapse disclosure element
    • इसे छोटे dropdown की तरह इस्तेमाल किया जा सकता है
    • इसमें मजबूत styling भी लागू की जा सकती है
  • <dialog>: dialog box element
    • यह buttons, forms, attributes और JavaScript से खोले-बंद किए जा सकने वाला built-in element है
    • यह बिल्कुल modal जैसा नहीं है, लेकिन modal बनाना हो to अच्छा आधार हो सकता है
    • यह संभवतः अगले elements के ऊपर render होता है
  • <i> aur <em>
    • इन दोनों elements के अंतर को समझना ज़रूरी है
  • <iframe>
    • इसे उदाहरण सूची में शामिल किया गया है, लेकिन मज़ाकिया अंदाज़ में लिया गया है
  • <input>: form input element
    • input के लिए उचित label और type का उपयोग करना चाहिए
    • mobile पर संदर्भ के अनुसार OS अलग keyboard खोलता है, इसलिए input type तय करना महत्वपूर्ण है
    • समय-संबंधित input के कई विकल्प होने से अलग JavaScript date picker की ज़रूरत कम हो सकती है
    • उदाहरण के तौर पर color, range, datetime-local inputs दिए गए हैं
  • <mark>: text highlight element
    • default रूप से Safari में यह पीले highlight के रूप में दिखता है
  • <meter>: measurement value दिखाने वाला element
    • Safari में सेट किए गए parameters के अनुसार यह लाल·पीला·हरा दिखता है
    • optimum value सेट की जा सकती है
    • यह 60fps music visualization demo में उपयोगी हो सकता है
  • <progress>: progress दिखाने वाला element
    • यह एक native HTML progress bar है, जिसमें fixed value या indeterminate state दी जा सकती है
    • Safari में window active होने पर यह नीला और inactive होने पर धूसर दिखता है
    • default रूप से यह system accent color का पालन करता है, और CSS की accent-color property से इसे सेट किया जा सकता है

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

1 टिप्पणियां

 
GN⁺ 2023-08-03
Hacker News की राय

  • यह कहना अजीब है कि HTML बंद ecosystem lock-in का समाधान है। ऐसी बंद services भी पहले से HTML इस्तेमाल करती हैं, और बताए गए कुछ semantic elements के साथ-साथ ज़्यादा refined ARIA semantic attributes भी इस्तेमाल करती हैं
    यह दावा भी कि ChatGPT जैसे interfaces इंसानों के data access का भविष्य हैं—AI systems की खास बात तो यही है कि input process करने के लिए उन्हें विशेष “machine-readable” annotations की ज़रूरत नहीं होती। ChatGPT और आगे के models इंसानों की तरह सामान्य websites browse कर सकते हैं, और बिना explicit markup के भी समझ लेते हैं कि paragraphs का कोई समूह “list” है
    लेखक जो समझा रहे हैं, वह आखिरकार HTML semantic elements के ज़रिए एक API जैसा ही है। लेकिन अगर API है, तो automated data access के लिए large language model की ज़रूरत नहीं; Beautiful Soup इस्तेमाल करने वाली एक साधारण Python script काफी है, और उसका फायदा यह भी है कि वह सिर्फ local पर run होती है

    • मुझे लगता है यह बात को बहुत छोटा करके देखना है। “HTML” भी होता है, और ऐसी websites भी होती हैं जिनका final DOM तभी तय होता है जब user उसे 10 सेकंड तक पढ़ने की कोशिश कर चुका होता है। इन दोनों extremes के बीच browser features कितने इस्तेमाल करने पड़ते हैं, इसमें बहुत बड़ा फर्क है
      आखिर अच्छा और बुरा अलग करने वाली चीज implementation complexity है। कोई भी tool अच्छा या बुरा इस्तेमाल किया जा सकता है, और कोई beginner circular saw और charged battery से बड़ा हादसा भी कर सकता है। कोई craftsperson tool बिल्कुल न इस्तेमाल करने और बगल में ठोकने—यानी business requirements के खिलाफ जाने—का चुनाव भी कर सकता है
      हाल में बनाई गई websites मेरी बनाई चीज़ों में सबसे ज़्यादा compatible हैं। अब मैं websockets इस्तेमाल नहीं करता, और JavaScript के server से टुकड़ों-टुकड़ों में बात करने के तरीके पर निर्भर नहीं रहता। JavaScript पूरी तरह बंद कर दें तो भी product का करीब 80% इस्तेमाल किया जा सकता है। समझ नहीं आता कि ऐसे engineering choices बंद ecosystem lock-in का समाधान कैसे नहीं हैं
    • “ChatGPT और आगे के models इंसानों की तरह सामान्य websites browse कर सकते हैं” यह अभी तथ्य से ज़्यादा एक दावा लगता है। फिर भी, अगर मान लें कि यह संभव है, तो बात दिलचस्प है
      large language models text और source code वगैरह पर train होते हैं, लेकिन जिसे reasoning device कहा जा सके वैसी चीज़ की कमी के साथ क्या वे DOM tree देखकर सच में समझ सकते हैं कि वह क्या है और क्या करता है? DOM text नहीं है, और bundling या componentization का नतीजा होने से उसे अच्छी तरह structured source code भी कहना मुश्किल है। यह लगभग ऐसा सुनाई देता है जैसे “large language model किसी भी .exe को देखकर तुरंत integrate कर सकता है”
    • मुझे लेख का मतलब यह लगा कि JavaScript-only divs के ढेर की जगह, या उसके साथ-साथ, HTTP के ऊपर machine-readable semantic content इस्तेमाल किया जाए। इससे नई लहर के large language models जैसे automated agents बिना headless browser चलाकर page render किए अहम details आसानी से निकाल सकेंगे
      मेरी भी मिलती-जुलती रुचि है, लेकिन उद्देश्य crawling और नए search engines हैं। अगर हर page को index करने से पहले headless browser में execute करना पड़े, तो नए search engine के लिए entry barrier काफी बढ़ जाता है
    • यह उचित point है। विडंबना यह है कि semantic markup का मुख्य फायदा अब human developers के लिए styling और control आसान बनाने वाला abstraction बन गया लगता है
    • क्या सच में ChatGPT ऐसा कर सकता है? क्या वह असल में ऐसा करता है?

  • लेख का पहला वाक्य है, “large language model-आधारित AI के आने से semantic HTML पहले से कहीं ज़्यादा महत्वपूर्ण हो गया है,” लेकिन मेरे हिसाब से “large language model-आधारित AI के आने से semantic HTML पहले से कहीं कम महत्वपूर्ण हो गया है” कहीं ज़्यादा defend की जा सकने वाली बात है
    semantic web विफल रहा, और उसकी जगह Google ने उस समय के top-tier AI से जुड़े तमाम heuristics पर बहुत पैसा खर्च करने वाले तरीके ने ले ली। AI जितना बेहतर होता जाएगा, किसी भी तरह बनाए गए jumble से जानकारी निकालने की क्षमता उतनी बढ़ेगी; और अगर ऐसा jumble पर्याप्त है, तो लोग मेहनत भी बस वहीं तक करेंगे। सिद्धांत रूप में आखिरकार semantic web और heuristics के ढेर—दोनों की जगह AI ले लेगा
    यह भी अहम है कि शुरू में LLM लिखा गया और बाद में सामान्य शब्द AI पर switch कर दिया गया। large language model पूरी AI नहीं है; यह अभी लोकप्रिय एक शाखा भर है, और आखिरी लोकप्रिय शाखा भी नहीं। आने वाले दशकों की projection इस assumption पर करना ठीक नहीं कि large language models ही AI का final answer हैं

    • क्या आप मानते हैं कि AI semantic HTML और ARIA पर आधारित web accessibility तक हल कर देगा? अगर नहीं, तो web content को accessible सुनिश्चित करने के लिए अब भी इंसानों की ज़रूरत है, और उस हालत में semantic HTML महत्वपूर्ण बना रहेगा
    • large language models के बाद search engine optimization कैसा दिखेगा, यह जानने की उत्सुकता है
      अगर लक्ष्य content के relevant हिस्सों का पर्याप्त अच्छे से index होकर rank करना है, तो कहा जा सकता है कि semantic HTML को पूरी तरह अपनाने का incentive कम था
      अगर लक्ष्य “rank करना” से बदलकर “large language model को content की nuance और texture अधिकतम extract करने देना” हो जाए, तो कुछ specific elements को बेहतर इस्तेमाल करने का incentive बढ़ सकता है। ऐसा करने वाली websites large language model के output पर ज़्यादा प्रभाव रख सकती हैं
      यह उतना जोर से बोलने और इतना स्पष्ट बोलने के फर्क जैसा लगता है कि बात समझ में आ जाए
    • क्या schema.org और Wikidata/Wikipedia अभी भी Google के अधिकांश rich search results को support नहीं कर रहे?
      सुना था कि Bard वाला नया results page announce हुआ है, लेकिन शायद ads ignore करने की आदत की वजह से या मेरे region में अभी नहीं आया इसलिए मैंने देखा नहीं; जाकर देखना पड़ेगा
    • AI जादू जैसा लगता है। मैंने हमेशा सोचा था कि इंसानों की pattern recognition क्षमता काफी अनोखी और replicate करना मुश्किल है। websites के jumble को देखते हुए किसी तरह data extraction करते समय हम वही क्षमता इस्तेमाल करते हैं
      मन से मैं semantic web camp के करीब था, लेकिन अगर machine उस jumble को ठीक-ठाक समझ सकती है, तो फिर मेहनत क्यों करनी—यह बात सही है
    • data resources बनाकर AI से वे resources इस्तेमाल करवाने की कोशिश करने वाले projects असली बात चूक रहे हैं। AI खुद data resource है
      कुछ projects दावा करते हैं कि knowledge graph या दूसरे data assets AI को “true” knowledge search करने में मदद कर सकते हैं। व्यक्तिगत रूप से मुझे लगता है कि AI को अपने data assets बनाने देने के तरीके विकसित करना बेहतर होगा। neural network के weights भी ऐसे assets में से एक हैं
      truth की समस्या अब भी बहुत कठिन है। AI को कैसे बताया जाए कि कौन-सा knowledge दूसरे knowledge से ज़्यादा भरोसेमंद है? बेशक इंसानों के साथ भी यही समस्या है

  • मैंने इन HTML elements में से ज़्यादातर के बारे में लगभग कभी नहीं सुना था, और यह काफ़ी अफ़सोस की बात है। क्योंकि ऐसी चीज़ें “हर चीज़ के लिए JavaScript चाहिए” वाले ecosystem को खत्म करने में काफी मदद कर सकती हैं
    कम-से-कम JavaScript को उसकी मूल मंशा के ज़्यादा करीब वाली जगह पर वापस ला सकती हैं—यानी थोड़ी सजावट या interaction जोड़ने के साधन के रूप में। इसे सारे markup का विकल्प और पूरे DOM का manager बनने की ज़रूरत नहीं है
    मेरे सपनों का browser शायद visurf https://sr.ht/~sircmpwn/visurf/ जैसा होगा, जिसमें अंदर का Netsurf engine ऐसे elements सहित modern HTML+CSS को support करने के लिए update किया गया हो। ऐसे browser से लगभग JavaScript-रहित छोटा web बनाया जा सकता है। screen reader, system theme, shortcuts वगैरह कम टूटेंगे तो accessibility बेहतर होगी, बदले जा सकने वाले भारी JavaScript उपकरणों की तुलना में बहुत कम resources लगेंगे, और आज के मध्यम स्तर के web apps से जिन ज़्यादातर चीज़ों की उम्मीद होती है वे भी संभव लगती हैं। WebGL जैसी चीज़ों के लिए Firefox खोल सकते हैं, लेकिन उदाहरण के लिए Matrix client भी websockets और end-to-end encryption भर के लिए थोड़ी-सी JavaScript जोड़कर बन सकता है

    • ऐसे built-in components की आम समस्या यह है कि theme apply करना मुश्किल होता है। किसी modern app के बीच में Windows 7 style का component अचानक दिख जाए तो बहुत खटकता है
      extensibility भी लगभग नहीं होती, इसलिए ज़रा-सी जटिल चीज़ करनी हो तो आखिरकार उसे छोड़कर JavaScript से फिर शुरू करना पड़ता है। तब शुरुआत से ही JavaScript से शुरू करना बेहतर है, क्योंकि वह ठीक काम करता है, पूरा control देता है और हर system पर एक जैसा चलता है
      अंत में ऐसे extra components ऐसी bloating बनकर रह जाते हैं जिन्हें सभी browsers को implement करना पड़ता है, लेकिन कोई इस्तेमाल नहीं करता
    • datalist को पहली बार देखकर लगा था, “वाह, game changer है।” Behavior browsers में एक जैसा है, लेकिन look पूरी तरह browser-specific है और CSS से style नहीं किया जा सकता
      कभी-कभी सिर्फ data का text दिखता है, और कभी text के साथ value attribute भी दिखता है। इसलिए “Atlanta” चुनने के बजाय “234290780 Atlanta”, यानी ID और value साथ में चुननी पड़ती है
      click behavior में भी ID सीधे नहीं मिलती; पूरा content लेकर ID parse करनी पड़ती है। यह बस एक छोड़ा हुआ element जैसा महसूस होता है
    • यह आपको पसंद आ सकता है: http://youmightnotneedjs.com/
    • मैं कुल मिलाकर इस विचार के खिलाफ नहीं हूँ, लेकिन ये elements बहुत पहले से मौजूद हैं। अगर HTML की आलोचना को गंभीरता से लिया जाना है, तो बुनियादी बातें जाननी चाहिए
      लेख MDN को link करता है, और छोटे reference के तौर पर MDN सबसे उपयोगी में से है। बेशक WHATWG HTML specification भी है, और अगर वह बहुत विशाल लगे तो WHATWG HTML 2021·2023 snapshots के लिए SGML DTD format grammar और पुराने HTML 5.x series grammar भी हैं
      [1]: https://sgmljs.net/docs/html200129.html
    • https://qutebrowser.org

  • मैं semantic web पर भरोसा करना चाहता हूँ, और यह भी मानना चाहता हूँ कि browsers अच्छे default modules और ठीक-ठाक default styles दे सकते हैं, लेकिन अभी ऐसा नहीं है—यह स्वीकार करना ही पड़ता है
    input पर label लगाना ही लें: पहले यह सोचना पड़ता है कि यह attribute क्यों नहीं है, फिर यह भी पक्का नहीं होता कि इसे wrapper के रूप में इस्तेमाल करें या for= attribute वाले sibling के रूप में रखें। यह तो बस हिमशैल की नोक है। हर tag के लिए उसका पूरा development history सीखना पड़ता है और आज सही तरीका क्या है, यह फिर से खोजना पड़ता है
    हमारे पास अच्छी चीज़ हो सकती थी, लेकिन अब शायद शांत होकर उसे छोड़ देना चाहिए

    • आप कौन-सा tool इस्तेमाल करते हैं, यह नहीं पता इसलिए यह किसी खास व्यक्ति के लिए नहीं है, लेकिन अगर web developers ने React, Tailwind आदि सीखने में लगने वाले समय का थोड़ा हिस्सा भी HTML सीखने में लगाया होता, तो web कहीं बेहतर स्थिति में होता
      निश्चित रूप से इसमें अजीब हिस्से और rough edges हैं, लेकिन अगर हर web developer semantic HTML का अधिकतम उपयोग करना जानता, तो browsers में JavaScript बहुत कम होता, accessibility bugs भी कम होते, और specification को जब ऐसी अजीब चीज़ों को ठीक या replace करना होता तो शायद उस पर ज़्यादा लोगों की नज़र होती
    • अगर input label HTML attribute होता, तो forms बहुत कम flexible होते। दो visual elements को एक में मिला दिया जाता, जिससे display adjust करना मुश्किल हो जाता। उदाहरण के लिए बाईं तरफ right-aligned label वाला input, या दाईं तरफ label वाला checkbox सोचिए
      label attribute शायद plain text content का मतलब रखता, जो बहुत सीमित लगता है
      HTML कई दशकों से इस्तेमाल हो रहा है, इसलिए इसका history जटिल और कई layers वाला है। फिर भी हाल में यह बहुत ज़्यादा नहीं बदला है, और MDN की वजह से HTML5 में क्या संभव है यह सीखना और ज़रूरत पड़ने पर और गहराई में जाना काफी आसान है
    • मेरे मामले में मैं लगभग हमेशा label tag को input tag के बाद रखना चाहता हूँ। इससे CSS pseudo-classes के जरिए input state के आधार पर label को select और style किया जा सकता है
    • हर tag का अर्थ सीखना किसी भी semantic tagging system का मूल हिस्सा है। अगर आपको यह विचार पसंद नहीं है, तो आप semantic web की अवधारणा से मूल रूप से मेल नहीं खाते
      बेशक किसी भी publishing system, बल्कि किसी भी system को प्रभावी ढंग से इस्तेमाल करने के लिए उसके दिए गए basic elements का उपयोग सीखना पड़ता है। इसलिए यह सिर्फ semantic web की समस्या नहीं है

  • Go HTML templates debug करने के लिए मैं details बहुत इस्तेमाल करता हूँ
    {{if .DevMode}} से development mode में data डाल देता हूँ; बंद रहने पर यह page को ज्यादा खराब नहीं करता इसलिए ज्यादा ध्यान नहीं खींचता, और ज़रूरत पड़ने पर खोलकर पूरा content देखा जा सकता है

    • हो सके तो मैं details element का थोड़ा ज़्यादा इस्तेमाल करता हूँ। यह बहुत साफ-सुथरा है, समझ नहीं आता कि इसे ज़्यादा क्यों नहीं इस्तेमाल किया जाता
    • web page में collapsible menu जैसी कई चीज़ों के लिए इस्तेमाल किया जा सकता है
      GitHub Markdown में भी इस्तेमाल किया जा सकता है, और कुछ लोग इसे examples या inline explanations के लिए भी इस्तेमाल करते हैं

  • पढ़ने की सामग्री और interactive demos अच्छे लगे
    Flutter के साथ कुछ साल काम करने के बाद फिर उसी निष्कर्ष पर पहुँचा: दांव HTML पर लगाना चाहिए
    Astro / Tailwind / Daisy UI / Alpine.js का कॉम्बिनेशन ऐसे HTML साइट्स बनाने के लिए अच्छा है जिनमें सरल server-side rendering ज्यादा हो और client-side responsiveness थोड़ी छिड़की गई हो
    नतीजा सरल और ठीक-ठाक HTML files होता है, जो desktop web browser और mobile-wrapped WebView में अच्छे दिखते हैं और ठीक काम करते हैं। मेरा ऐप असल में static है, इसलिए CDN में cache हो जाता है, offline भी चलता है, और View Source debugging को आसान बना देता है

    • कई चमकदार frameworks और platforms आज़माने के बाद आखिरकार मैं भी Alpine.js और Tailwind इस्तेमाल करने वाली static site पर आ गया। अब तक लिए गए फैसलों में यह साफ तौर पर सबसे अच्छा था
      सबसे अच्छी बात यह है कि नया developer चाहे React, Angular, PHP, या Python background का हो, मुझे भरोसा है कि वह 100-line build file को करीब 3 मिनट देखकर समझ जाएगा। यह सचमुच इतना सरल है कि अच्छा लगता है
    • मेरे हिसाब से Flutter से web export करना लगभग nightmare है। आखिरी बार जब देखा था, rendering canvas में हो रही थी, और markup बिल्कुल नहीं था
    • क्या कोई Daisy UI की उपयोगिता समझने में मेरी मदद कर सकता है? यह ऐसा लगता है जैसे पुराने style की classes + stylesheet को Tailwind नाम के एक extra step के जरिए इस्तेमाल कर रहे हों
    • सही है, Astro और islands architecture के साथ काम करना सचमुच मजेदार है

  • मेरे हिसाब से semantic web की समस्या यह है कि चाहे इसे कितना भी आसान बना दिया जाए, developers इसे सही तरह इस्तेमाल करने से इनकार करते हैं। मेरा browser extension main tag का इस्तेमाल करता है, इसलिए मैं इस tag पर ध्यान देता रहा हूँ; MDN docs में क्या करना चाहिए यह बहुत साफ है, और docs खुद भी अच्छे usage examples दिखाते हैं। फिर भी इसे सही इस्तेमाल करने वाली sites बहुत कम हैं
    यहाँ तक कि चमकदार professional sites भी अक्सर navigation, footer वगैरह सहित पूरे page content को main tag के अंदर wrap कर देती हैं। यह tag सिर्फ page के मुख्य content के लिए होना चाहिए
    अगर इतना सरल element भी सही से इस्तेमाल नहीं हो पाता, तो बाकी elements से ज्यादा उम्मीद नहीं है

    • यह HTTP verbs गलत इस्तेमाल करने वाले developers वाली ही श्रेणी है
      ऐसी चीजों को contract होने का दिखावा नहीं करना चाहिए
    • जिस developer ने paragraphs के लिए p tag इस्तेमाल किया, उसने सचमुच उसे सही इस्तेमाल किया। यह class="card" जैसी चीज से अलग है
      समझ नहीं आता कि तकनीकी समझ रखने वाले इतने लोग semantic web की बेकारियत या उसकी विफलता पर इतना अफसोस क्यों जताते हैं। यह ऐसा सुनाई देता है जैसे कोई कहे, “काश car सफल हो जाए, लंबी दूरी की यात्रा आसान हो जाएगी”
    • पहले दिमाग में आने वाला हल है ज्यादा सख्त validation: अगर structure सही न हो तो browser rendering से इनकार कर दे
      लेकिन ऐसा दौर रहा है। HTML4 से पहले की चीजें मोटे तौर पर ऐसी ही थीं, और वह और भी खराब था
      इसलिए शायद developer tools का गलत usage पर warnings या errors देना बेहतर होगा
    • सही तरीके से इस्तेमाल करने का कोई incentive नहीं है। मैं भी सही इस्तेमाल करने की कोशिश करता हूँ, लेकिन किस element को क्या होना चाहिए यह तय करने में समय लगाने के अलावा कोई फर्क नहीं पड़ा

  • दिलचस्प है कि यहाँ कई comments इस लेख को anti-JavaScript लेख की तरह देख रहे हैं। मुझे तो ये उल्टा उन tools जैसे लगते हैं जो modern enterprise app frontends में हमारे TypeScript-centric frameworks के साथ इस्तेमाल करने पर बेहद उपयोगी होंगे। क्योंकि ये HTML native tools हैं, इसलिए बहुत ज्यादा चीजों की मांग नहीं करते
    उदाहरण के लिए, meter tag शायद आज office पहुँचते ही React में इस्तेमाल होने वाले हमारे सारे loading modules की जगह ले लेगा। क्योंकि यह अभी जो हम इस्तेमाल कर रहे हैं उससे काफी बेहतर है
    हो सकता है मैंने लोगों को गलत समझा हो या लेख गलत पढ़ा हो, लेकिन आज की बड़ी applications की तरह frontend लगभग पूरा TypeScript होने पर भी यह बहुत दिलचस्प है

    • मेरी उम्मीद है कि ये चीजें JavaScript code के बड़े-बड़े ढेरों की जगह लेंगी। मुझे पता है कि JavaScript-विहीन web दुर्भाग्य से एक कल्पना है, लेकिन कम से कम बड़े हिस्से हटाकर ऐसा ज्यादा standard user experience बनाया जा सकता है जिसे system guide और shape कर सके
      नई applications बन सकती हैं जिन्हें पहले से कहीं कम JavaScript में बनाया जा सके। मौजूदा enterprise TypeScript apps में यह in-place upgrade हो सकता है, लेकिन उम्मीद यह है कि नए app development में उन enterprise frameworks को ही avoid किया जा सके। सपने तो देख ही सकते हैं, है न?

  • मैं वेब डेवलपमेंट को पूरी तरह नीचा नहीं दिखाना चाहता, लेकिन यह सच में भयानक है। कच्चे HTML से लेकर scripting languages और frameworks तक, मैं यह काम कई सालों से कर रहा हूँ, और छोटी-सी चीज़ करने में लगने वाला समय बहुत बड़ा दिमागी अपव्यय लगता है
    छुट्टी पर गया था तो बस खाने-पीने की जगहें या दिनभर घूमने की जगहें ढूँढना चाहता था, लेकिन ज़्यादातर साइटें बिखरी हुई, पुरानी या अपडेट न की हुई थीं। एक बार बनाकर भूल जाने वाली साइटें अब भी बहुत हैं। शायद बजट तंग है इसलिए अपडेट करने की गुंजाइश नहीं, या अपडेट करना तकनीकी रूप से बहुत कठिन है
    साइट की जटिलता ही ठहराव ले आती है। जहाँ साधारण text और images के कुछ pages काफी होते, वहाँ बेवजह over-engineering करके बहुत सारे CPU cycles जलाए जा रहे हैं। यह भी काफी संभव है कि किसी तैयार CMS को तोड़-मरोड़कर बनाया गया हो, जिसे security updates चाहिए होते हैं
    हाल में एक सिनेमा हॉल की साइट देख रहा था, और उस हफ्ते चल रही कुछ फिल्मों को सरसरी तौर पर देखना भी लगभग असंभव था। लगा कि spreadsheet में डालना पढ़ने में बेहतर होगा, और सच में API से JSON डाउनलोड करके देखा तो वही ज़्यादा पढ़ने योग्य था
    ज़्यादातर चीज़ें सूअर पर lipstick लगाने जैसी थकाऊ पैकेजिंग हैं। Facebook के सफल होने की एक वजह आसान onboarding थी, और दूसरी वजह photos share करना आसान होना था। WhatsApp और Instagram भी ऐसे ही हैं। publishing आसान होनी चाहिए। साधारण FTP भी आसान तो है, लेकिन आम लोगों के लिए usability प्रक्रिया में एक अजीब टूटन है। लोग drag and drop, upload, छोड़कर भूल जाना, और आसान editing चाहते हैं। जो लोग data consume करना चाहते हैं, वे आखिर में सिर्फ मूल चीज़ चाहते हैं। यानी data

    • मुझे नहीं लगता कि data consume करने वाले लोग सिर्फ मूल data चाहते हैं। औसत HN reader ऐसा हो सकता है, लेकिन औसत व्यक्ति नहीं
      लोग जो चाहते हैं वह अच्छी तरह styled और usable webpage है। समस्या यह है कि प्रभावी और प्रतिभाशाली user experience designers पर्याप्त नहीं हैं, और company stakeholders में भी ठीक-ठाक UX sense की कमी है
      इसलिए औसत company जिस कमजोर UX को afford कर सकती है, उससे बेहतर स्थिति औसत user के लिए सिर्फ core data देना बन जाती है। भले ही वह उनकी पसंद न हो, फिर भी वह बेहतर है
      {खराब UX} << {raw data} < {अच्छा UX}
      WordPress ने जो workaround निकाला वह यह था कि professional styles और themes बनाए जाएँ और users उन्हें खरीदकर apply करें। लेकिन stakeholders की खराब पसंद को इससे भी ठीक नहीं किया जा सकता
      मेरे हिसाब से Facebook इसलिए सफल हुआ क्योंकि उसने professional और standardized UX enforce किया। {लोगों का data} + {professional और standardized UX} = {जीत}। शुरुआती Facebook UX आपको नापसंद हो सकता है, लेकिन उसे amateur-level काम कहना मुश्किल है। MySpace या Geocities वगैरह के बारे में आम धारणा इसके उलट थी
    • WhatsApp का ज़िक्र करने वाला हिस्सा बिल्कुल सही बात पकड़ता है। मैं जिस अफ्रीकी देश में हूँ, वहाँ WhatsApp इतना लोकप्रिय है कि mobile carriers WhatsApp data bundles तक बेचते हैं
      अगर मुझे wire mesh जैसी कोई चीज़ ढूँढनी हो, तो पहले अपने WhatsApp groups—परिवार, मोहल्ले, high school दोस्तों के groups—में पूछता हूँ। आमतौर पर कुछ नंबर मिल जाते हैं, और service provider से WhatsApp पर संपर्क करने पर ताज़ा जानकारी मिल जाती है
      वे service providers updated website afford नहीं कर सकते। WhatsApp में profile में catalog डालने का feature भी है, और यह free business accounts के लिए है
    • इसलिए ज़्यादातर छोटे कारोबारियों को मैं Wix recommend करता हूँ। क्या सारी sites एक जैसी दिखती हैं? हाँ, और यह ज़रूरी नहीं कि बुरा ही हो। इस्तेमाल और update करना आसान है, इसलिए customer जरूरी ताज़ा जानकारी मिलने के लिए आभारी रहता है
      मैं “Wix Widgets” जैसी चीज़ देखना चाहूँगा। data-connected widgets, जिनमें REST service calls जोड़ने और data points को widget display से map करने जितनी customization हो। आजकल हर company में जो internal website requirements होती हैं, उन्हें संभालने में यह काफी मददगार होगा
      webpages के 90–95% हिस्से को वाकई सरल समाधान चाहिए
    • यह मज़ेदार है कि web platform को सबसे अच्छा और consistent cross-platform GUI system बताया जाता है, फिर भी उसी system पर कुछ बनाना भयानक है
      शायद यह GUI की प्रकृति ही हो, ऐसा भी सोचता हूँ। हर instruction एक-एक करके देनी पड़ती है, बहुत cycles खाती है, और ऐसा न हो तो cross-platform काम नहीं करती—शायद इसकी बनावट ही ऐसी है
    • इस समस्या का एक हिस्सा यह है कि HTML file में tags और elements लगातार बढ़ते जा रहे हैं। यह document markup नहीं, page markup बन गया है, और कहाँ एक खत्म होता है और दूसरा शुरू होता है, यह अलग करना मुश्किल है। हालाँकि W3C ने article और section elements जोड़कर कोशिश की थी
      बेशक raw HTML code शायद शुरू से developers के अलावा किसी और के पढ़ने के लिए बना ही नहीं था, तो वह पहलू भी है

  • pure HTML modal आने की खबर से मैं सच में उत्साहित था, लेकिन यह जानकर निराशा हुई कि JavaScript के बिना उसे trigger करने का कोई तरीका नहीं है। pure HTML से उसे सिर्फ बंद किया जा सकता है, खोला नहीं जा सकता
    https://github.com/whatwg/html/issues/3567
    dialog element शानदार addition है और खुशी है कि इसे implement किया जा रहा है, लेकिन इसकी core functionality का कुछ हिस्सा JavaScript पर निर्भर है। dialog खोलने के लिए JavaScript से open attribute set करना पड़ता है
    अच्छा हो अगर button या a element के पास dialog खोलने का कोई तरीका हो। HTML में built-in page interaction की मिसाल पहले से है। उदाहरण के लिए links page को scroll कर सकते हैं, और details element interaction के बाद elements छिपा सकता है, इसलिए कोई दूसरा page element dialog खोल सके तो यह स्वाभाविक लगेगा

    • अगर “HTML-only” जैसा ऊँचा लक्ष्य यह मतलब रखता है कि HTML में scripting capabilities बढ़ाई जाएँ, तो मुझे यकीन नहीं। ऐसे मामले में तो बस JavaScript इस्तेमाल करना बेहतर लगता है
    • JavaScript के बिना सिर्फ HTML और CSS से भी modal implement किया जा सकता है
      उदाहरण के लिए यहाँ ऊपर दाईं ओर ? पर click करके देखें: https://aavi.xyz/proj/colors/
    • HTML में ही built-in हो तो अच्छा होगा, लेकिन कम से कम जितनी JavaScript चाहिए वह जटिल नहीं है और onclick attribute में भी रखी जा सकती है
    • मौजूदा hash के आधार पर उसे दिखाया या छिपाया जा सकता है। बेशक उस तरीके में CSS की जरूरत तो होती है