HTML यह कर सकता है
आधुनिक HTML और CSS अब native रूप से बहुत अधिक इंटरएक्टिविटी संभाल सकते हैं—जैसे dialogs, popovers, grouped `<details>`, responsive images, और कुछ accordion- तथा tab-style UI—जिससे कई डेवलपर यह सवाल करने लगे हैं कि सामान्य interfaces के लिए भारी JavaScript frameworks या SPAs वास्तव में आवश्यक हैं या नहीं। टिप्पणीकार वास्तविक लाभों को रेखांकित करते हैं: तेज़ server-rendered pages, बेहतर baseline accessibility, और सरल architectures जो उन उपयोगकर्ताओं के लिए भी काम करती हैं जो JavaScript को block करते हैं या उसके बिना हैं। साथ ही, वे sharp edges और gaps भी बताते हैं—जैसे `<datalist>` और date pickers के लिए spotty support, सीमित styling और UX control, और sortable tables या अधिक शक्तिशाली comboboxes जैसे richer components की आवश्यकता—और तर्क देते हैं कि HTML आज के JS-driven patterns में से कुछ को बदल सकता है, लेकिन सभी को नहीं।
मूल HTML विजेट्स की क्षमताएँ और सीमाएँ
- कई लोग इस बात से प्रभावित हैं कि “केवल HTML” के साथ CSS जोड़कर अब कितनी इंटरएक्टिविटी संभव है (dialogs, popovers, details, view transitions)।
- अन्य लोग ज़ोर देते हैं कि कुछ सुविधाएँ अभी भी “लगभग वहाँ तक” ही हैं: उदाहरण के लिए,
datalistमें मज़बूत value constraints, fuzzy search, और अच्छा browser support नहीं है। - Native date pickers की व्यापक रूप से आलोचना होती है कि वे buggy हैं, browsers/OS के बीच असंगत हैं, और password managers द्वारा आसानी से तोड़े जा सकते हैं।
छुपी हुई सामग्री, <details>, और खोजयोग्यता
hidden="until-found"और<details>की सराहना की जाती है क्योंकि वे CTRL+F से collapsed सामग्री को सामने ला सकते हैं (FAQs, org charts, tabbed content)।- उपयोग के मामलों में “view terms/exclusions” panels, collapsible trees, और “skip to content” patterns शामिल हैं (हालाँकि यह focus styling से बेहतर हल होता है)।
- grouped/accordion व्यवहार को लेकर बहस है: कुछ चाहते हैं कि केवल एक
<details>खुला रहे; अन्य (UX research का हवाला देते हुए) auto-closing को निराशाजनक मानते हैं।
SPAs, JavaScript, और “HTML-First” दृष्टिकोण
- कई उपयोगकर्ता NoScript चलाते हैं और साइटों का मूल्यांकन इस आधार पर करते हैं कि उन्हें कितना third‑party JS चाहिए; वे उन साइटों की सराहना करते हैं जो अधिकतर बिना JS के काम करती हैं।
- बहुत से लोग SPAs को URLs, back button, और bookmarks तोड़ने के लिए नापसंद करते हैं; अन्य कहते हैं कि इसे proper routing और URL updates से हल किया जा सकता है।
- “server-rendered plus sprinkles” patterns (HTMX, minimal JS, View Transition API) और पूरी तरह JS-free UIs के प्रयोगों के लिए उत्साह है।
Dialogs, Popovers, और Declarative Actions
- नए popover/dialog/command attributes को consistent focus, stacking, accessibility, और zero-JS menus/tooltips/confirmations के लिए सराहा जाता है।
- आलोचक declarative actions API (
popovertarget,...action) को साधारण JS event handlers की तुलना में HTML को अनावश्यक रूप से जटिल बनाने वाला मानते हैं। - समर्थकों का तर्क है कि यह faster time-to-interactive, बेहतर SSR, और script-less interactivity सक्षम करता है; script attributes को disable किया जा सकता है, जिससे declarative bindings उपयोगी बनते हैं।
Tables, Sorting, और Layout बनाम Semantics
- कुछ लोग native sortable tables और यहाँ तक कि built-in virtualization भी चाहते हैं; अन्य ज़ोर देते हैं कि “that’s what JS is for” और browser bloat की चिंता करते हैं।
- headers में links के माध्यम से server-side sorting का बचाव simple और फिर भी performant होने के रूप में किया जाता है; अन्य multi-column, no-refresh sorting चाहते हैं।
- एक साइड बहस: HTML structure/semantics है या layout भी? कुछ कहते हैं tags परोक्ष रूप से layout का वर्णन करते हैं; अन्य specs का हवाला देते हैं कि layout CSS के लिए है।
Dates, Forms, और Localization
- ISO date formats लागू करने या page
langके साथ align करने के अनुरोध; मौजूदा OS-native formats उपयोगकर्ताओं और back-office workflows को भ्रमित करते हैं। - सुझाव:
<time>को वास्तव में display स्थानीयकृत करने दें, या हमेशा ISO submit करें जबकि localized formats को लगातार दिखाएँ।
Browser Support, Adoption, और Tooling
- चिंता है कि standards surface बढ़ने से नए engines बनाना कठिन हो जाता है; कुछ लोग नए features को, समर्थन होने पर भी, अपनाने में हिचकिचाते हैं।
- कहा जाता है कि LLMs और code generators नए HTML/CSS APIs के मामले में पीछे हैं, जिससे पुराने JS-heavy patterns को बल मिलता है, हालाँकि “skills” और guidance इससे कम कर सकती हैं।
विविध नोट्स
- Responsive images (
srcset,<picture>) पर चर्चा होती है;<picture>को केवलsrcsetकी तुलना में अधिक लचीला माना जाता है। <select>और color inputs जैसे native controls का कम उपयोग होता है, आंशिक रूप से क्योंकि उन्हें platforms के बीच समान रूप से style करना कठिन है.