इसके लिए आपको JavaScript की ज़रूरत नहीं है

 (htmhell.dev)
3 पॉइंट द्वारा GN⁺ 2023-12-03 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • वेब फीचर लागू करते समय HTML, CSS, JavaScript के क्रम में कम शक्तिशाली तकनीकों को पहले परखना लोड फेल होने और accessibility समस्याओं को घटाने में मददगार होता है
  • JavaScript ब्राउज़र के व्यवहार को सीधे नियंत्रित कर सकता है, लेकिन अतिरिक्त resources और error की संभावना के कारण keyboard और assistive technology users को बाहर कर देना आसान हो जाता है
  • checkbox switch, datalist, input type="color", details/summary, dialog जैसे फीचर, जिनके लिए पहले JavaScript चाहिए होता था, अब काफी हद तक HTML/CSS की built-in सुविधाओं से संभव हैं
  • HTML और CSS की declarative सुविधाएँ ब्राउज़र को native behavior, user preferences और accessibility handling संभालने देती हैं, जिससे बेहतर defaults मिल सकते हैं
  • भले ही परिचित JavaScript implementation अभी भी काम करती हो, आधुनिक HTML/CSS विकल्पों को समय-समय पर देखना चाहिए, और बदलाव करते समय accessibility testing भी साथ करनी चाहिए

न्यूनतम विशेषाधिकार का नियम

  • न्यूनतम विशेषाधिकार का नियम वेब development का सिद्धांत है, जिसमें लक्ष्य पूरा करने के लिए सबसे कम शक्तिशाली भाषा चुनने की सलाह दी जाती है
  • वेब में यह आम तौर पर HTML को CSS से पहले, और CSS को JavaScript से पहले विचार करने के रूप में लागू होता है
  • JavaScript इन तीनों तकनीकों में सबसे बहुमुखी है, लेकिन उतना ही भारी भी है
    • यह टूट सकता है
    • इसका लोड होना फेल हो सकता है
    • download, parsing और execution के लिए अतिरिक्त resources चाहिए होते हैं
    • keyboard users और assistive technology users को बाहर कर देना आसान होता है
  • HTML और CSS, imperative JavaScript के विपरीत, declarative तरीके से काम करते हैं
    • developer ब्राउज़र को बताता है कि वह क्या चाहता है, और उसे कैसे लागू करना है यह ब्राउज़र तय करता है
    • ब्राउज़र अधिक efficient processing तरीका चुन सकता है
  • जब ब्राउज़र HTML/CSS फीचर्स को संभालता है, तो performance, native behavior, user preference support और accessibility के लिहाज़ से फायदे हो सकते हैं
    • हालांकि accessibility हमेशा अपने-आप सुनिश्चित नहीं होती

वे फीचर जिनके लिए पहले JavaScript चाहिए होती थी

  • ब्राउज़र बनाने वाले और specification लिखने वाले लोग पिछले कुछ वर्षों में ऐसे फीचर्स को CSS और HTML में ला रहे हैं जिनके लिए पहले JavaScript चाहिए होती थी
  • वेब backward compatibility बनाए रखता है, इसलिए एक बार सीखी हुई implementation toolbox में बनी रहती है और बार-बार इस्तेमाल होने लगती है
  • अगर आपको लगता है कि किसी फीचर के लिए JavaScript ज़रूरी है, तो कभी-कभी यह जाँच लेना कि क्या आज भी ऐसा है, बेहतर वेबसाइट बनाने में मदद कर सकता है

checkbox से बना custom switch

  • custom switch को div, onclick handler और internal state के बजाय एक साधारण checkbox और CSS से बनाया जा सकता है
  • <label> के अंदर <input type="checkbox"> रखने पर ब्राउज़र दोनों को जोड़ देता है
    • label में कहीं भी click करने पर checkbox toggle हो जाता है
    • अलग onclick handler की ज़रूरत नहीं पड़ती
  • appearance: none ब्राउज़र के default form control rendering को रोकता है और आपको खुद styling करने देता है
    • input को ही switch background की तरह सजाया जा सकता है
    • ::before को toggle होने वाले inner dot की तरह इस्तेमाल किया जा सकता है
  • :checked pseudo-class checked state के अनुसार background color और ::before की position बदल सकता है
  • keyboard users के लिए focus indication ज़रूरी है
    • outline: none से focus छिपाना अच्छा तरीका नहीं है
    • :focus-visible केवल keyboard interaction के समय एक अच्छा focus ring दिखा सकता है
    • outline-offset से focus outline को element के बाहर या अंदर समायोजित किया जा सकता है
  • input:focus { outline-color: transparent; } सामान्य स्थिति में outline को transparent बना सकता है, और high contrast mode में user द्वारा चुने गए रंग में उसे फिर दिखा सकता है
  • forced colors mode के बारे में forced colors explained में और पढ़ा जा सकता है

datalist से native autocomplete

  • datalist ब्राउज़र की built-in auto-suggestion सुविधा है, जो user के टाइप करते समय options की सूची दिखाती है
  • इसका setup सरल है
    • datalist element में id और कई option रखिए
    • input की list attribute से उसे उस datalist से जोड़िए
  • user के टाइप करते ही ब्राउज़र dropdown दिखाता है और input के अनुसार options को अपने-आप filter करता है
  • क्योंकि यह एक सामान्य input field है, इसलिए user सूची में न होने वाला मान भी सीधे टाइप कर सकता है
  • input field चुनने के बाद arrow keys से सूची देखी जा सकती है, या ब्राउज़र द्वारा जोड़ा गया dropdown icon click करके सभी options देखे जा सकते हैं

input type="color" का built-in color picker

  • सिर्फ <input type="color"> की एक लाइन से ब्राउज़र का native color picker इस्तेमाल किया जा सकता है
  • यह JavaScript से बने कई canvas UI और sliders को replace कर सकता है
  • Chromium browsers का native color picker सिर्फ साइट के भीतर नहीं, बल्कि स्क्रीन पर कहीं से भी रंग चुन सकता है
  • क्योंकि हर user ब्राउज़र color picker इस्तेमाल नहीं कर सकता, इसलिए रंग चुनने का कोई दूसरा तरीका, जैसे सामान्य text input, साथ में देना बेहतर है

details और summary से accordion

  • details और summary elements content को खोलने-बंद करने वाला accordion ब्राउज़र की built-in सुविधा के रूप में देते हैं
  • इसका default behavior सरल है
    • details के अंदर का content, summary को छोड़कर, छिपा रहता है
    • user summary पर click करता है तो बाकी content दिखता है
  • open attribute शुरुआती open state तय करता है
    • यह user interaction के बाद स्थिर रहने वाला मान नहीं है; user खोलता और बंद करता है तो state बदलती रहती है
  • summary::marker से default triangle marker को style किया जा सकता है
    • content को emoji आदि से बदला जा सकता है
    • background color, background image, font size आदि बदले जा सकते हैं
    • कई CSS properties काम नहीं करतीं, और marker को बिल्कुल अलग जगह रखने जैसी styling सीमित है
  • Safari में ::-webkit-details-marker pseudo-element की ज़रूरत होती है
  • marker content बदलने से assistive technology द्वारा accordion की घोषणा करने के तरीके पर असर पड़ सकता है, इसलिए details/summary inconsistencies देखी जा सकती है
  • summary clickable होता है, लेकिन default रूप से न तो link की तरह pointer cursor दिखाता है और न button जैसा दिखता है, इसलिए hover और focus states जोड़कर उसकी clickability स्पष्ट करनी चाहिए

dialog से modal

  • alert(), prompt(), confirm() user को सूचना देने या पुष्टि लेने के काम आते हैं, लेकिन वे main thread को रोक देते हैं और design के हिसाब से style करना कठिन होता है
  • खुद dialog बनाने पर accessibility संभालना जटिल हो जाता है
    • focus को dialog के भीतर बनाए रखना पड़ता है
    • यह बताना पड़ता है कि यह modal है
    • user को गलती से बाहर निकलने से रोकना पड़ता है
    • बहुत ऊँचे z-index वाले widgets से टकराव हो सकता है
  • ब्राउज़र का dialog element native dialog देता है
  • अभी dialog खोलने के लिए JavaScript चाहिए
    • JavaScript के बिना खोलने वाला बदलाव प्रगति पर है, लेकिन अभी पूरी तरह specified या implemented नहीं है
    • showModal() function से dialog खोला जा सकता है
  • dialog top layer में खुलता है
    • top layer HTML से अलग एक नई layer है
    • इस layer के elements, z-index और stacking context nesting से स्वतंत्र होकर, हमेशा सबसे ऊपर दिखते हैं
    • अवधारणा के लिए MDN का Top layer देखा जा सकता है
  • dialog default close UI नहीं देता, इसलिए आपको खुद UI जोड़ना पड़ता है
    • form method="dialog" submit होने पर ब्राउज़र dialog बंद कर देता है
    • दो submit buttons में अलग-अलग value देने पर इसे confirm dialog की तरह इस्तेमाल किया जा सकता है
    • close event में dialog.returnValue पढ़कर पता किया जा सकता है कि user ने कौन-सा button दबाया
    • अतिरिक्त form data को FormData से पढ़ा जा सकता है
  • dialog::backdrop dialog और बाकी page के बीच की layer है
    • background को dark या blur करके user का ध्यान dialog की तरफ लाया जा सकता है
    • क्योंकि इसकी placement ब्राउज़र करता है, इसलिए scroll, fixed elements और browser resize को आपको खुद संभालने की ज़रूरत नहीं होती

कम JavaScript से संभव और फीचर

  • ऐसे और भी फीचर हैं जिनमें JavaScript घटाई जा सकती है
    • scroll-behavior: smooth से native smooth scrolling
      • इसे केवल तब उपयोग करने की शर्त है जब prefers-reduced-motion: no preference लागू हो
    • scroll-snap से native carousel
    • position: sticky से “in-view” elements
    • container queries
  • आगे और फीचर भी आने वाले हैं
    • scroll-driven animations
    • masonry.js के बिना grid-template-rows: masonry से Masonry layout
    • नए selectlist element के ज़रिए पूरी तरह style किया जा सकने वाला select
    • :has() selector, जो JavaScript selection code की एक श्रेणी को कम कर सकता है
  • प्रस्तुति वीडियो Stop Using JavaScript for That: Moving Features from JS to CSS and HTML. में इससे जुड़ी और बातें देखी जा सकती हैं
  • मौजूदा tested implementation को नए तरीके से बदलते समय, खासकर accessibility की testing ज़रूर करनी चाहिए ताकि कोई भी बाहर न रह जाए

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

1 टिप्पणियां

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

  • इस लेख में जो बात छूट गई है, वह यह है कि ऐसी जगहों पर JavaScript इस्तेमाल करने की वजह बेहतर compatibility है
    नई JavaScript को transpile किया जा सकता है, लेकिन गायब CSS या HTML features को polyfill करना कहीं ज्यादा मुश्किल है और कुछ मामलों में असंभव भी। ऊपर से वे polyfill भी आखिरकार JavaScript ही इस्तेमाल करते हैं
    appearance के बारे में MDN पर भी, यहां तक कि appearance: none के लिए भी, अच्छी तरह test करने की काफी चेतावनियां हैं। अगर सिर्फ आधुनिक browsers को support करना हो तो यह कम अहम हो सकता है, लेकिन पुराने Safari versions उम्मीद से ज्यादा लंबे समय तक बने रहते हैं
    datalist Firefox Android में कुछ भी नहीं करता, और मुझे तो यह सुझावों के बिना सिर्फ एक input box जैसा दिखता है
    color picker अच्छा है, लेकिन बेहद non-standard है, इसलिए ज्यादातर businesses के लिए यह गंभीर समस्या है। बात सिर्फ designers के शिकायत करने की नहीं है; customer support के लिए users की मदद करना मुश्किल हो जाता है। Chromium page से color pick करने या कोई arbitrary color चुनने तक की सुविधा देता है, लेकिन Firefox Android सिर्फ rainbow, gray, black-white जैसी चीजें देता है
    लेख खुद भी details और dialog की असंगति स्वीकार करता है। उम्मीद है कि किसी दिन ऐसे browsers इस्तेमाल में नहीं रहेंगे जो इन features को support नहीं करते या आपस में consistent तरीके से support नहीं करते, लेकिन फिलहाल ये elements शायद उन्हीं side projects में इस्तेमाल होंगे जहां supported browsers पर पूरा control हो

    • color picker को non-standard कहना मुझे मान्य नहीं लगता
      iPhone पर button दबाने से असली system-native color picker खुलता है। यह वही control है जो OS देता है और कई apps में दिखता है, और मुझे custom-made control की तुलना में यह कहीं ज्यादा पसंद है
    • compatibility बेहतर है, यह तभी सही है जब यह मानकर चला जाए कि सभी users JavaScript इस्तेमाल करेंगे
      मुझे JavaScript-रहित web कहीं ज्यादा पसंद है, और laptop battery life पर भी इसका असर कई घंटों तक पड़ता है। कुछ sites इसके साथ compatible नहीं होतीं और खाली page render करती हैं या text दिखाने के लिए JavaScript चाहिए, ऐसी शिकायत करती हैं
      दूसरी तरफ Amazon के पास JavaScript के बिना चलने वाली e-commerce site की एक replica भी है, जो दिखाता है कि इतना बड़ा काम भी JavaScript के बिना संभव है
    • dialog element की support coverage अब काफी गहरी है, और 2021 के दौर वाले Firefox या Safari इस्तेमाल करने वाले कुछ प्रतिशत users के लिए polyfill भी काफी ठीक है
      अगर modal बना रहे हैं तो मैं इसकी जोरदार सिफारिश करूंगा, accessibility improvements शानदार हैं
    • customer support के लिए users की मदद करना मुश्किल हो जाना बड़ी बात है
      पिछली job में हमने इस समस्या पर सक्रिय रूप से चर्चा की थी, और datalist जैसी चीजों के बजाय JS implementation इस्तेमाल करने का फैसला किया था। खासकर datalist को आजमाया था, लेकिन नतीजे इतने inconsistent थे कि छोड़ना पड़ा
      अंत में browserों के बीच inconsistency की वजह से Chrome के अलावा बाकी support भी बंद करना पड़ा
    • नहीं। JavaScript fail होती है तो पूरी तरह fail होती है, और content ही गायब हो जाता है
      HTML examples पुराने browsers में गलत दिख सकते हैं, लेकिन वास्तविक content बचा रहता है। JS में बस कुछ भी नहीं होता। यह accessibility को पूरी तरह तोड़ देता है
      HTML हो तो screen reader कम से कम पढ़ सकता है, लेकिन JS से generated content उसमें बाधा डालता है। जब JS, JS चला ही नहीं सकती, तो कोई polyfill या दूसरा JS भी JS को नहीं बचा सकता। शुरुआत से ही “काम” करना जरूरी है तभी यह accessibility के लिहाज से ठीक है, और उस स्थिति में असली मुद्दा ही निरर्थक हो जाता है

  • मुझे Datalist के बारे में पता नहीं था, लेकिन कम से कम Chrome Android पर यह ठीक से काम करता हुआ नहीं लगता
    options autocomplete suggestions दिखने वाले keyboard area में दिखते हैं: https://imgur.com/a/Ecb4503
    mobile web UI के form controls में ऐसा तरीका मैंने पहली बार देखा है, और password autocomplete apps द्वारा वही जगह इस्तेमाल करने के अलावा कभी नहीं देखा
    बुरा नहीं है। ढंग से न बने custom JS dropdown को awkward तरीके से scroll करने से यह काफी बेहतर है, लेकिन मुझे भरोसा नहीं कि आम user इसे इस्तेमाल करने का तरीका समझ पाएगा। इसलिए mobile पर मैं इसे व्यावहारिक रूप से बेकार मानता हूं
    Firefox Android में यह बिल्कुल support नहीं होता: https://caniuse.com/?search=datalist

    • browser बनाने वालों, क्या datalist dropdown पर style apply करना संभव नहीं कर सकते?
      संदर्भ: https://adrianroselli.com/2023/06/under-engineered-comboboxe...
    • ऐसे solutions को व्यापक रूप से स्थापित होने में लंबा समय लगने की वजह यही है
      JavaScript काफी अच्छी तरह standardized है, लेकिन HTML और CSS तुलनात्मक रूप से कम हैं
    • सोच रहा हूं कि input element में autocomplete="off" जोड़ने से behavior बदलता है या नहीं
      वैसे भी datalist को ठीक से इस्तेमाल करने के लिए यह जरूरी है। नहीं तो value selection history dropdown list में जुड़ जाती है। Chromium में यह देखा है
      इसके अलावा, जैसे default value set होने पर, कुछ स्थितियों में datalist को अभी भी JS की जरूरत होती है। workarounds और browser-specific quirks के notes नए LibreOffice website code में जमा कर रखे हैं: https://git.libreoffice.org/infra/libreofficeorg/+/835a5cc59...
      अच्छी खबर यह है कि Firefox developer datalist behavior सुधारने पर गौर करने की योजना बना रहे हैं, जिससे शायद एक click में list दिखाना संभव हो सके
    • keyboard के ऊपर देखा?
      मेरे मामले में options keyboard के ऊपर उसी area में दिखते हैं जहां आम तौर पर word suggestions दिखते हैं
    • datalist options का keyboard के अंदर दिखना पिछले कुछ महीनों में आया बदलाव है
      पहले यह “सामान्य” था, लेकिन लगता है किसी ने सिर्फ बदलने के लिए बदलना चाहा

  • scroll-behavior: smooth से native smooth scroll इस्तेमाल करना कृपया बहुत सीमित रूप से ही करना चाहिए
    उम्मीद से ज़्यादा ज़्यादातर use cases में यह अच्छा विचार नहीं होता, और अनचाहे side effects अक्सर होते हैं
    कहा जाता है कि scroll-snap से native carousel बनाया जाता है, लेकिन carousel अब भी खराब idea है, इसलिए scroll-snap का वैध उपयोग क्षेत्र बेहद सीमित है
    scroll-based animation इस्तेमाल करने वाले pages आम तौर पर उसे हटाने पर बेहतर हो जाते हैं

    • इस लेख का मकसद यह निर्देश देना नहीं है कि कौन सा design element इस्तेमाल करें, बल्कि यह दिखाना है कि ऐसे design को ज़्यादा user-friendly तरीके से कैसे implement किया जाए
      smooth scroll इसका अच्छा उदाहरण है। native API user को कभी भी रोकने की सुविधा देती है। ज़्यादातर JS implementations भयानक रूप से अटकते हैं और user को परेशानी होती है
      design choice को आप जितना चाहें डांट सकते हैं, लेकिन अगर “carousel अब भी खराब है” के वास्तविक कारण नहीं देंगे, तो उम्मीद करना मुश्किल है कि लोग सुनेंगे
    • मुझे भी carousel पसंद नहीं हैं
      लेकिन Amazon homepage carousel का काफ़ी प्रमुखता से इस्तेमाल करता है, और मेरी जानकारी में Amazon homepage variants का बेरहमी से A/B test करता है। तो संभव है कि carousel tests में अच्छा निकला हो, और किसी universal, objective अर्थ में उसे सचमुच “खराब” कहना थोड़ा अस्पष्ट है
    • native smooth scroll ज़्यादातर मामलों में अच्छा idea क्यों नहीं है?
      आम तौर पर table-of-contents style anchors implement करने के तुरंत बाद मैं कम से कम इसे add करता हूँ
    • जो भी हो, उन चीज़ों के लिए JavaScript की ज़रूरत तो नहीं है

  • हैरानी की बात है कि 2023 में भी हम अब भी forms और user के data input करने वाली सामान्य UX को लेकर बहस कर रहे हैं
    datalist और color picker से जुड़े comments ही देख लें; समझ नहीं आता कि यह क्षेत्र अभी तक solve क्यों नहीं हुआ
    पहले XForms के ज़रिए इसे एक ही बार में solve करने की कोशिश हुई थी, लेकिन browsers में implement नहीं हुआ
    इसके बजाय लगभग हर CSS/JS component framework सीमित form elements के अपने-अपने bundle देता है, जिनकी semantics अलग-अलग होती हैं

    • XML technologies को ठुकराने का नतीजा यह हुआ कि web की किस्मत में XML जो देता था उसके घटिया versions को अंतहीन रूप से reimplement करना लिख दिया गया
      लगता है हम ज़िंदगी भर basic UI controls खुद implement करते रहेंगे
    • यह पहले ही solve हो चुका है। इसे React में डालिए और ज़िंदगी आगे बढ़ाइए
      “solve नहीं हुआ” ऐसा सिर्फ इसलिए लगता है क्योंकि कुछ लोग JavaScript से बचने की अजीब ज़िद में आधे-अधूरे alternatives को जबरन fit करने की कोशिश करते हैं
    • forms “solve हो गए” इसका मतलब क्या है?
      अगर boring और basic technology तक रहना है, तो यह पहले ही solve है। लेकिन अगर React से दोबारा solve करने, React hooks से फिर solve करने, और अंतहीन बार फिर से solve करने पर अड़े रहेंगे, तो यह unsolved बन जाता है
    • CSRF की वजह से कुछ ऐसी चीज़ें हैं जो इंसान कर सकता है, लेकिन हम नहीं कर सकते
      intention को programmatically निर्धारित नहीं किया जा सकता, इसलिए कुछ स्थितियों में शानदार features नहीं हो सकते
      जिस आखिरी complex form पर मैंने काम किया, उसमें browser की अनुमति के लिए click event से form submission काफी सीधे तौर पर trigger करवाना पड़ा था
    • forms इसलिए solve नहीं हुए हैं क्योंकि कोई न कोई, कहीं न कहीं, forms से अलग-अलग चीज़ें submit करना चाहता है
      मैंने कभी web page के ज़रिए रंग submit करने का तरीका नहीं मांगा

  • JavaScript की जगह details इस्तेमाल करने पर Ctrl+F उसके अंदर search कर सकता है और उसे खोल सकता है
    JavaScript accordion ऐसा नहीं खोल सकता

    • hidden="until-found" इस्तेमाल करने पर JS-based accordion या दूसरे hidden content में भी यह संभव हो जाता है, लेकिन अफसोस कि अभी यह सिर्फ Chromium-based browsers में है: https://developer.chrome.com/articles/hidden-until-found/
    • क्या search allow करते हुए hide करने का कोई और तरीका है?
    • docs देखते हुए अभी-अभी मुझे भी ऐसी ही problem हुई

  • ज़्यादातर बातों से सहमत हूँ, लेकिन dialog को इतना इस्तेमाल नहीं किया कि राय दे सकूँ, और datalist को internal tools के अलावा वैध option नहीं मानता
    यह बदसूरत है, इसकी capabilities सीमित हैं, और style भी नहीं कर सकते। “बस built-in feature इस्तेमाल करो” वाली ज़्यादातर दलीलों की समस्या यही है। date picker भी ऐसा ही है
    default ही खराब नहीं है, बल्कि अगर बदलना चाहें तो बदल भी नहीं सकते। style या behavior बदलने में जब आप अनगिनत दीवारों में से किसी एक से टकराते हैं—जैसे week को Monday से शुरू करना चाहें और न हो सके—तो विकल्प अक्सर JS वाली पूरी replacement library ही रह जाता है
    मैं हल्के options इस्तेमाल करने के पक्ष में हूँ और HTML > CSS > JS वाली hierarchy से भी सहमत हूँ, लेकिन अच्छा दिखने वाला UI और desired features दोनों पाने के लिए कभी-कभी JS ही एकमात्र जवाब होता है

    • search suggestion box implement करते समय मैंने सोचा कि datalist मददगार होगा या नहीं
      यह तब तक ठीक चला जब तक मुझे ऐसे options दिखाने की ज़रूरत नहीं हुई जो typed content से strictly start नहीं होते। उदाहरण के लिए input में typo हो तो options दिखाई नहीं देते
      सभी items को force करके दिखाने का कोई तरीका नहीं था, इसलिए आखिरकार मैंने ordered list चुनी
    • यह हमेशा याद रखने लायक है कि built-in semantic markup को JS से extend करना future-oriented approach है
      जब मैंने web development शुरू किया था, बदलावों में 10 साल तक लग जाते थे। IE6 ने भी हम सबको रोके रखा, लेकिन उस समय w3c भी काफी कमजोर था। अब बदलाव तेज़ हैं
      अगले साल तीनों major browsers में datalist styling बिना prefix के संभव हो सकती है, लेकिन अगर आप custom JS solution से बंधे हैं, तो business rebuild का खर्च नहीं देगा
      native features को JS से extend करने पर, support पर्याप्त हो जाने पर कम cost में JS हटाया जा सकता है। जहाँ native control acceptable हों, वहाँ अभी इस्तेमाल करें, और JS को polyfill की तरह apply करें
    • week start day या input[type=date] के लिए आम तौर पर सुझाए जाने वाले ज़्यादातर customizations पर developer का control न होना ही बेहतर है
      दिखाया जाने वाला सही calendar locale-dependent होना चाहिए। user का platform पहले से ही उसे उस तरीके से set और display करने की क्षमता रखता है जिसे user सबसे प्रभावी ढंग से इस्तेमाल करने की संभावना रखता है
      platform का date picker आपके खुद बनाए अजीब solution से बेहतर है

  • वह toggle button वाकई अच्छा है
    लगता है इस लेख पर frontend meme developers भड़क रहे हैं, लेकिन मूल बात सही है। इतनी सारी बेवकूफी भरी sites JS से क्यों बनाई जाती हैं? अगर लोग HTML जैसे एक ही standard का पालन करें, तो सब कुछ consistent हो सकता है, और accessibility या translation जैसी चीजें भी आसानी से सही की जा सकती हैं
    आजकल sites खोलकर देखें तो सब कुछ single page में dynamically load करने के चक्कर में back button तक काम नहीं करता

    • लोग HTML जैसे एक standard का पालन करें, तब भी browser बनाने वालों को implementation consistent रखना होगा
      और नई feature आने के बाद उसके पर्याप्त व्यापक support पाकर उपयोगी बनने तक कई साल लग सकते हैं—यानी “लोगों के update करने का इंतजार” वाली समस्या फिर भी रहती है
      खराब implementations और जटिल JavaScript जुगाड़ बहुत हैं, इससे मैं काफी हद तक सहमत हूँ। dynamic content में भी back functionality बनाए रखने के standardized solutions काफी हैं, और मेरी जानकारी में popular web frameworks इन्हें default रूप से support करते हैं
    • क्या वे सचमुच भड़क रहे हैं?
      मैंने top comments पढ़े, लेकिन ऐसा कुछ खास नहीं दिखा जिसे गुस्सा कहा जाए; बस लोग browser support को लेकर valid points उठा रहे हैं

  • सही दिशा में एक कदम तो है, लेकिन CSS भी एक और tool है जिसका Philip Greenspun के कहे “artistes” पढ़ने में मुश्किल pages बनाने के लिए दुरुपयोग करते हैं
    मैं Gemini समर्थक नहीं हूँ, लेकिन मूलतः layout और typography के हर पहलू को browser के पास वापस जाना चाहिए और user के control में होना चाहिए। designers ने बार-बार दिखाया है कि उन पर यह भरोसा नहीं किया जा सकता

  • मंशा पसंद है, switch भी बढ़िया है, और summary/details भी कभी-कभी उपयोगी होते हैं
    लेकिन datalist element खिलौनों या prototypes से आगे के use cases में लगभग कभी practical विकल्प नहीं होता

  • मेरी पसंदीदा “JS के बिना CSS ही काफी है” वाली चीजें sidebar drawer और carousel हैं
    DaisyUI नाम की TailwindCSS component library में भी ready-to-use components हैं
    https://daisyui.com/components/drawer/
    https://daisyui.com/components/carousel/

    • drawer को screenreader को कैसे announce कराते हैं?
      drawer और page पर दिखने वाला दूसरा content announce होना चाहिए, और जिस control से यह जुड़ा है उसके पास aria-expanded state होनी चाहिए
      यह अभी भी सचमुच का सवाल है। शायद कोई तरीका हो, या developers collectively इसे important न मानते हों। हालांकि auditors सहमत नहीं होंगे
    • ऐसे frameworks देखकर शुरुआत में हमेशा उम्मीद बंधती है, लेकिन जिन दूसरे frameworks को मैंने test किया है उनकी तरह DaisyUI में भी iOS Safari और दूसरे browsers पर कई समस्याएँ हैं
      लगता है ऐसे frameworks के authors बहुत कम आंकते हैं कि browsers के across सच में काम करवाने के लिए कितनी testing चाहिए
      components इतने ज्यादा हों, और ऊपर से theming भी possible हो, तो यह भी भरोसे से कहना मुश्किल है कि existing themes और applications को तोड़े बिना fix किया जा सकेगा या नहीं
    • components/carousel/ में “Snap to [start|center|end]” पहली बार देखा
      आखिर snap है क्या और कैसे काम करता है? मेरी screen finger click पर respond नहीं करती
      मुझे नहीं लगता कि अनजाने interaction patterns किसी UI element library की अच्छी recommendation का आधार हैं