आधुनिक HTML/CSS की कम-ज्ञात सुविधाएँ

• हाल की वेबसाइट performance गिरावट का एक बड़ा कारण JavaScript का अत्यधिक उपयोग और tracking scripts हैं, जबकि कई मामलों में इन्हें सिर्फ HTML/CSS से ही पर्याप्त रूप से बदला जा सकता है
• हाल में जोड़ी गई सुविधाएँ जैसे CSS nesting, relative colors, नए viewport units (lvh, svh, dvh) उन कामों को आसान बनाती हैं जिनके लिए पहले JS या preprocessor पर निर्भर रहना पड़ता था
• CSS सिर्फ एक style tool नहीं, बल्कि animation, input validation, dark mode theme, accordion menu तक लागू कर सकने वाली एक शक्तिशाली भाषा है
• performance के लिहाज़ से भी CSS, GPU acceleration और अलग thread पर चलकर animation और transition effects में JS से अधिक smooth और efficient हो सकती है
• लेखक CSS को सिर्फ एक practical tool नहीं बल्कि अभिव्यक्ति और कला के माध्यम के रूप में रेखांकित करते हैं, और web developers से आधुनिक CSS की क्षमता का अधिक उपयोग करने की सलाह देते हैं

---

परिचय: वेब की जटिलता, और नए प्रयास

• कई वेबसाइटें JavaScript frameworks के अत्यधिक उपयोग के कारण performance गिरावट और जटिलता का सामना कर रही हैं
  • React app लोड होने में कई सेकंड लेते हैं, और NextJS hydration errors पैदा करता है
  • node_modules फ़ोल्डर कई gigabytes जगह घेर लेता है
• बिना JavaScript के भी सिर्फ HTML और CSS से शक्तिशाली सुविधाएँ लागू की जा सकती हैं
  • जटिल shopping cart या dashboard वाली e-commerce sites को छोड़ दें, तो JavaScript हमेशा अनिवार्य नहीं हो सकता
• यह लेख CSS की नई सुविधियों का परिचय देता है और developers को केवल JavaScript पर निर्भर हुए बिना अन्य संभावनाओं की खोज करने के लिए प्रेरित करता है

CSS को लेकर गलतफहमियाँ और धारणा

क्या CSS सच में कठिन और असुविधाजनक है?

• CSS को लेकर नकारात्मक धारणा अक्सर बुनियादी सीख की कमी से आती है
  • कई developers CSS की बुनियाद छोड़कर JavaScript या TypeScript पर ध्यान केंद्रित करते हैं
  • CSS सिर्फ एक styling tool नहीं, बल्कि शक्तिशाली सुविधाएँ देने वाली domain-specific language है
• CSS में flexbox जैसे tools के साथ जटिल layout भी आसानी से बनाए जा सकते हैं
  • उदाहरण: display: flex और justify-content: center से div को केंद्र में रखना आसान है
  • browser developer tools flexbox properties को visually adjust करने के लिए widgets देते हैं
• अगर कोई सिर्फ एक पक्ष (जैसे JS) में बहुत गहराई तक जाए और CSS की अनदेखी करे, तो बोझ बढ़ना स्वाभाविक है

CSS लिखने की तकलीफ़, और बदलाव

• पहले CSS उतना सुविधाजनक नहीं था, इसलिए Sass और Tailwind जैसे tools आए
  • उदाहरण: .post > .buttons .like:hover जैसी लंबी selector chains को manage करना पड़ता था
• हाल के वर्षों में quality-of-life features (जैसे nesting) जुड़ने से अब सिर्फ मूल CSS से भी आराम से development करना संभव हुआ है
  • CSS nesting संबंधित styles को एक ही जगह रखकर readability बढ़ाता है
    • उदाहरण: .post { & > .buttons { .like { &:hover { ... } } } }
    • parent-child संबंध स्पष्ट हो जाता है, इसलिए छोटे और सरल class names इस्तेमाल किए जा सकते हैं
• relative colors रंगों को adjust करना आसान बनाते हैं
  • hsl(from #123456 h s calc(l + 10)) से brightness बदली जा सकती है
  • color-mix() से दो रंग मिलाकर dynamic colors बनाए जा सकते हैं
• media query range syntax (width <= 768px) जैसे intuitive conditions सेट करने देता है
• lh unit line height के अनुसार styling का समर्थन करती है
• scrollbar-gutter property scrollbar के कारण होने वाले layout shift की समस्या हल करती है
• Baseline प्रमुख browsers में feature compatibility सुनिश्चित करता है
  • newly available features नवीनतम browsers में काम करती हैं
  • widely available features 2.5 साल पुराने browsers तक समर्थित होती हैं
  • उदाहरण: CSS nesting को दिसंबर 2023 से सभी browsers में support मिला

सिर्फ CSS/HTML से विकास क्यों?

• कुछ users JavaScript को default रूप से disable रखते हैं, जैसे security या privacy कारणों से
• यदि वेबसाइट सिर्फ CSS/HTML से उपलब्ध कराई जाए, तो ऐसे users के लिए भी site का उपयोग संभव होने की संभावना बढ़ जाती है
• development और user experience दोनों के दृष्टिकोण से सिर्फ CSS/HTML इस्तेमाल करने पर speed, accessibility, CPU और battery usage में फायदे हैं
  • CSS animations compositor thread पर चलती हैं, इसलिए CPU पर दबाव कम होता है
  • JavaScript event loop के ज़रिए चलता है, इसलिए थोड़ा delay हो सकता है
• accessibility और usability बेहतर होती है
  • button hover effects, toast animations, input validation जैसी चीजें CSS से सरलता से लागू की जा सकती हैं

CSS के व्यावहारिक उदाहरण और मुख्य सुविधाएँ

@starting-style से स्वाभाविक शुरुआती animation लागू करना

• पहले elements के entry animation लागू करने के लिए keyframes, JS triggers जैसी जटिल संरचना चाहिए होती थी
• @starting-style आने से शुरुआती state तय करना आसान हो गया है। element की initial-state animation (जैसे fade-in) आसानी से लागू की जा सकती है
  • transition: opacity 1s; @starting-style { opacity: 0; } से सेट किया जा सकता है
  • अलग @keyframes या JavaScript के बिना भी काम करता है
• सिर्फ transition के साथ शुरुआती state बताने पर animation स्वाभाविक रूप से लागू हो जाती है
  • उदाहरण: toast message की opacity और position transition को smooth बनाना

dark/light mode के लिए आसान theme setup

• color-scheme: light dark user preference के अनुसार theme अपने-आप बदलता है
• light-dark(#000, #FFF) function light/dark mode के लिए उपयुक्त रंग निर्धारित करता है
• radio buttons और :has selector से user theme selection का समर्थन किया जा सकता है
  • JavaScript के बिना सिर्फ CSS से theme switching संभव है
  • theme को save/load करने के लिए वैकल्पिक रूप से JavaScript जोड़ा जा सकता है

radio/checkbox और :has, :checked से custom UI बनाना

• tabs, accordion, toggles जैसी जटिल interactions भी JavaScript के बिना लागू की जा सकती हैं
• radio buttons को :checked और :has के साथ custom style किया जा सकता है
  • उदाहरण: label:has(input:checked) से selected button की style तय की जा सकती है
  • opacity: 0 से input element को छिपाया जा सकता है, जबकि screen reader accessibility बनी रहती है
• details element FAQ जैसे accordion menu लागू करने के लिए उपयुक्त है
  • name attribute से single-open state नियंत्रित की जा सकती है
  • [open] state के अनुसार animation जोड़ी जा सकती है

input validation और state reflection

• pattern, required जैसे HTML attributes और CSS pseudo-classes (:valid, :invalid, :user-valid आदि) के संयोजन से real-time validation और visual feedback दिया जा सकता है
• input fields के outline/border style बदलकर user experience बेहतर किया जा सकता है
• HTML के pattern attribute से input field validity check की जा सकती है
  • उदाहरण: \w{3,16} से 3–16 अक्षर, अंक या underscore की अनुमति
• CSS के :valid और :invalid validity के आधार on styling करते हैं
  • :user-valid और :user-invalid केवल user के input करने के बाद style लागू करते हैं
• :has selector से input state के अनुसार दूसरे elements की styling की जा सकती है
• कुछ मामलों में (जैसे जटिल input conditions) JS की ज़रूरत पड़ सकती है, लेकिन अधिकतर स्थितियों में CSS/HTML पर्याप्त है

viewport units का सही उपयोग

• मोबाइल में address/navigation bar के दिखने-छिपने के कारण vw/vh units में accuracy issues आती हैं
• lvh/svh/dvh (largest/smallest/dynamic viewport height) जैसे नए viewport units इस्तेमाल करने की सलाह दी जाती है
  • lvh: full-screen उपयोग के लिए, जैसे full background
  • svh: उन buttons, links आदि के लिए जो हमेशा स्क्रीन पर दिखने चाहिए
  • dvh: scroll जैसी बदलती परिस्थितियों के अनुसार flexible sizing के लिए
• keyboard overlay को interactive-widget property या VirtualKeyboard API से संभाला जा सकता है
  • <meta name="viewport" content="width=device-width, interactive-widget=resizes-content">
  • Chromium-आधारित browsers में navigator.virtualKeyboard.overlaysContent = true

CSS wishlist: कमी महसूस होने वाली या चाही गई सुविधाएँ

• reusable blocks: class के भीतर दूसरी class apply करना (जैसे @apply border)
• combined media query selectors: @media और class selector का संयोजन
• nth-child variable: span { --nth: nth-child(); } से dynamic styling
• nth-letter selector: किसी खास अक्षर की styling (जैसे p::nth-letter(2))
• unit removal: calc(100vw / 1px) से unit-less values बनाना
• image() function: fallback colors और image fragments का समर्थन
• body के अंदर style tag: आधिकारिक standard support से FOUC समस्या कम करना

निष्कर्ष: CSS, और वेब की कलात्मकता

• CSS सिर्फ एक tool नहीं, बल्कि रचनात्मक अभिव्यक्ति का माध्यम है
• AI tools या build chain (linter, minifier) रचनात्मकता को सीमित कर सकते हैं
• CSS एक साथ performance, accessibility, और कलात्मक अभिव्यक्ति को पूरा करता है
• यह लेख लगभग 49kB के JavaScript-रहित HTML/CSS से लिखा गया है
  • सभी interactive widgets और visual elements हाथ से बनाए गए हैं
  • उदाहरण: CSS click game CSS की programming-language जैसी संभावनाओं का प्रमाण है

[duqduqduq]

मैं full-stack था, लेकिन जैसे-जैसे करियर ऊपर की ओर बढ़ता गया, FE करने के मौके कम होते गए। करीब 10 साल तक मैंने इसे लगभग छुआ ही नहीं, फिर हाल ही में एक कंपनी में lecture देने का मौका आया तो सोचा संक्षेप में परिचय देने के लिए थोड़ा देख लूं, और यह देखकर सचमुच हैरान रह गया कि चीजें कितनी बदल चुकी हैं। scss तक साथ में हो तो और भी बढ़िया लगता है। लेकिन CSS का यह क्षेत्र सच में बड़ा अजीब है। सीखना आसान है, मगर इतना अच्छा इस्तेमाल करना कि लोगों से पहचान मिले, यह काफी हद तक व्यक्ति की aesthetic sense और creativity पर निर्भर करता है। ऐसे web दौर में जहाँ usability और design को ज्यादा महत्व दिया जाता है, यह देखकर अफसोस होता है कि publisher की value शायद उतनी ऊंची नहीं आंकी जाती।

[ahwjdekf]

इस बार वेब डेवलपमेंट टेक्नोलॉजी को हल्के-फुल्के शौकिया तौर पर आज़माते हुए, बिना किसी बुनियादी ज्ञान के बिल्कुल शून्य से nextjs, authjs, tailwind, shadcn का इस्तेमाल करके एक बेसिक बोर्ड बना कर देखा... और सीखने की सबसे बड़ी कठिनाई CSS रही।

[GN⁺]

Hacker News राय

• मुझे CSS में हाल ही में जो nesting फीचर जोड़ा गया है, उसके लिए आभार है, लेकिन कुल मिलाकर देखें तो CSS वाकई बहुत अजीब है, और व्यक्तिगत रूप से मुझे यह एक खराब भाषा लगती है। हो सकता है कि वजह यह हो कि मैं इसे ठीक से इस्तेमाल नहीं कर पाता, लेकिन यह इतनी जटिल और बेतरतीब लगती है मानो किसी अज्ञात रून लिपि को इधर-उधर खिसका रहा हूँ। styling और layout system आपस में मिले हुए हैं, लेकिन inheritance और containment के रिश्ते अलग होने से यह और उलझा देता है। मुझे लगता है कि styling और layout को मिलाना ही एक गलती थी। जो system पहले से बुनियादी स्तर पर टूटा हुआ है, उसमें बस नए फीचर जोड़ते जाना समाधान नहीं हो सकता.

  • मैं भी पिछले 10 साल से CSS से ही रोज़ी-रोटी कमा रहा हूँ, लेकिन CSS किसी ठीक से डिज़ाइन की गई भाषा से ज़्यादा ऐसा लगता है जैसे समय-समय पर उसे बढ़ाया गया हो। पुरानी properties के ऊपर नए modules चिपका दिए गए हैं, इसलिए वे आपस में टकराते हैं या थोड़ा अलग व्यवहार करते हैं, जिससे debugging मुश्किल हो जाती है। उदाहरण के लिए box model और flex layout का अलग तरह से काम करना, या gap property का flex और grid में अलग तरह से व्यवहार करना (लिंक)। एक बार layout बना लेने के बाद वह व्यवहारिक रूप से लगभग स्थिर हो जाता है। जटिल native या JS-आधारित encapsulation के बिना उसे लचीले ढंग से बदलना कठिन है। फिर अनपेक्षित रूप से font weight बदल जाना या mobile menu का desktop पर भी दिखने लगना जैसी समस्याएँ आती हैं.
  • मैं सहमत नहीं हूँ। मेरा मानना है कि CSS के बारे में नकारात्मक राय इसलिए ज़्यादा दिखती है क्योंकि लोगों ने इसे ठीक से सीखा नहीं, खासकर cascade को समझा नहीं। मैंने एक समय CSS spec को गहराई से पढ़ा था, और तब मुझे लगा कि markup के अर्थ और style को अलग रखने के उद्देश्य के लिए यह काफ़ी अच्छी तरह डिज़ाइन की गई भाषा है.
  • मुझे नहीं लगता कि styling और layout को अलग करना संभव है। जिसने भी UI development किया है, वह जानता है कि ये दोनों तत्व मूल रूप से एक-दूसरे में गुंथे हुए और परस्पर निर्भर हैं। जैसे text की लंबाई या size, overflow, margin, padding वगैरह सब एक-दूसरे को प्रभावित करते हैं। किसी element की border या spacing बदलने से उसके अंदर के content की जगह भी बदल जाती है। इन दोनों को पूरी तरह अलग नहीं किया जा सकता.
  • मुझे लगता है कि CSS की असली समस्या Cascading है, और आधुनिक frontend development का बड़ा हिस्सा दरअसल इसी cascade को रोकने के लिए घूमता है। UI का componentization इसका उदाहरण है। layout अपने आप में अलग समस्या है, और compatibility की वजह से यह और जटिल हो जाता है। अगर सारे layout मूल रूप से सिर्फ flexbox या grid से काम करते, और inline तथा non-inline को एक container में न मिलाया जाता, तो चीज़ें बहुत बेहतर होतीं। React Native बिल्कुल ऐसे ही काम करता है। React Native में styles cascade नहीं होते, इसलिए उन्हें मैनेज करना कहीं आसान है.
  • यह सब बातें सही हैं, लेकिन फिलहाल हमारे पास यही है। मैंने सोचा है कि क्या कोई अधिक वैचारिक रूप से सुसंगत model बनाया जा सकता है जिसे CSS में transpile किया जाए। container queries या calc जैसी चीज़ों से शायद अधिक व्यवस्थित layout system को गणितीय रूप से लागू किया जा सकता है। मौजूदा preprocessor भाषाएँ तो CSS के ऊपर, जिसमें पहले से अधूरे concepts हैं, फिर और अधूरे फीचर जोड़ देती हैं, जिससे उलझन और बढ़ती है.

• CSS की सबसे बुरी बात, मेरे हिसाब से, यह है कि बहुत से लोग इसे ठीक से सीखे बिना बस एक दिन मजबूरी में इस्तेमाल करते हैं और फिर बहुत तीखी राय बना लेते हैं.

  • मेरा भी ऐसा एक "दिन" था। मैं podcast app बनाते समय एक floating footer बनाना चाहता था जो (1) हमेशा नीचे रहे, (2) हमेशा दिखे, (3) content को ढके नहीं, और (4) बिना अलग hacks के implement हो जाए। लेकिन तब पता चला कि CSS में यह संभव नहीं है। क्या ही शानदार system है.
  • मैंने CSS 20 साल पहले सीखी थी, और मेरा निष्कर्ष यह है कि Cascading की वजह से CSS का नाम बदलकर Crappy Style Sheets कर देना चाहिए। जब कई लोग मिलकर काम करते हैं, तो "यहाँ कुछ बदलो और उधर कुछ अजीब टूट जाए" जैसी स्थिति सामान्य हो जाती है। rules को override करने के जटिल नियम इसकी पहचान हैं, और अगर यही इसकी बुनियाद है तो यह अच्छी बात नहीं। जटिल targeting के तरीके और जटिल होते जाते हैं, और अंत में कोड .foo > .bar:nth-child(2n) ~ .baz जैसा दिखने लगता है। फिर उससे सहकर्मी का कोड टूट जाता है। एक साधारण layout भी सिरदर्द बन जाता है। हालाँकि हाल के वर्षों में चीज़ें काफ़ी सुधरी हैं, लेकिन शुरू से यह cascade-केंद्रित संरचना ही समस्या रही है। syntax वगैरह पर दूसरी आलोचनाएँ मामूली हैं। अगर कोई चीज़ व्यावहारिक और इस्तेमाल में आसान हो, तो syntax बर्दाश्त की जा सकती है, लेकिन CSS ऐसी नहीं थी। मुझे नहीं लगता कि web layout बनाना अपने-आप में एक पेशा होना चाहिए.
  • "बहुत से लोग CSS सीखे बिना इस्तेमाल करते हैं" इस बात पर, यह कहना कि किसी को इसे इस्तेमाल करने का हक़ तभी है जब वह 20 से ज़्यादा specs पूरी पढ़ ले, बहुत कठोर रवैया है। अगर लोग किसी tool का उपयोग करते समय समस्या झेलते हैं, तो पहले tool में समस्या है या नहीं यह देखना चाहिए, लोगों को दोष नहीं देना चाहिए। जैसे आरी चलाते समय सिर्फ सावधान रहने को कहने के बजाय उस पर safety guard लगाना बेहतर है.

• मुझे इस लेख में "कुछ users JavaScript नहीं चाहते" वाला तर्क बहुत प्रभावी नहीं लगा। मैं खुद Arch user हूँ और तरह-तरह की scripting और crawling में रुचि रखता हूँ, लेकिन "NoScript" environment पर ध्यान केंद्रित करना मुझे ख़ास महत्वपूर्ण नहीं लगता। यह बहुत छोटे समूह की पसंद है, इसलिए इसे आम तौर पर नज़रअंदाज़ किया जा सकता है। यह कुछ-कुछ उस दौर जैसा लगता है जब कहा जाता था कि "10% लोग IE6 इस्तेमाल करते हैं"। फिर भी, CSS के बेहतर होने के और भी बहुत से कारण हैं। वैसे भी यह मुख्य मुद्दा नहीं है, बस बहस का रुख मुझे ऐसा लगा.

  • जो काम मैं CSS में declarative तरीके से कुछ पंक्तियों में कर सकता हूँ, वही JS में imperative तरीके से करने पर दर्जनों पंक्तियाँ ले लेता है, ज़्यादा अजीब व्यवहार आता है, framework compatibility issues पैदा होते हैं, और interactive होने में देरी होती है। NoScript environment तो बस अतिरिक्त लाभ है। सच कहूँ तो मन ही मन मुझे DSSSL की याद आती है.
  • मूल लेख में JavaScript से बचने वाले users का ज़िक्र बस किनारे से आता है, लेकिन ज़्यादातर लेख CSS features को दिखाने पर केंद्रित है। प्रेरणाओं में performance भी है, लेकिन CSS तकनीकों का परिचय देना कहीं ज़्यादा उत्पादक तरीका लगता है.
  • मैं रोज़मर्रा में NoScript environment के साथ इंटरनेट इस्तेमाल करता हूँ। जिन sites पर JS ज़रूरी है, सिर्फ उन्हीं को exception देता हूँ। performance, battery, और security के लिए यह काफ़ी अच्छा है। क्या आपने कभी एक हफ़्ते से ज़्यादा NoScript के साथ बिताया है? इस्तेमाल करने से पहले मेरी राय भी ऐसी ही थी। वैसे, मैं ही इस blog post का लेखक हूँ.
  • मुझे नहीं लगता कि NoScript users इतनी अहम audience हैं कि उन्हें target करना ज़रूरी हो, लेकिन लेखक ने जिस बात को बस हल्के से छुआ है, वह यह कि कम code लिखना और browser platform पर ज़्यादा भरोसा करना बहुत बड़ी value देता है। browser को जितना संभव हो उतना काम करने देना बेहद कुशल है.
  • "कुछ users JavaScript नहीं चाहते" इस दावे पर, मुझे लगता है कि लगभग सभी users JavaScript नहीं चाहते.

• मुझे पता ही नहीं था कि nesting अब आधिकारिक standard बन चुकी है। हाल तक मैं समझता था कि यह अभी भी proposal stage में है। CSS में अजीब बातें बहुत हैं, लेकिन JavaScript की तरह यह भी धीरे-धीरे बेहतर भाषा बनती जा रही है। Flexbox, :has selector, और nesting की वजह से पुराने कई pain points काफ़ी हद तक दूर हुए हैं.

• मेरी wishlist में मौजूद CSS के दो features तो पहले से spec में हैं.

  • n-th child variables को sibling-index() और sibling-count() से implement किया जा सकता है (MDN विवरण)
  • reusable blocks के लिए @function और @mixin draft spec मौजूद है (spec draft, CSS Tricks विवरण)
  • दोनों Chrome में पहले से implement हो चुके हैं और उपयोग किए जा सकते हैं.

• मुझे CSS syntax खराब लगती है। मैं 10~15 भाषाओं के साथ काम करता हूँ, लेकिन CSS सबसे कठिन है पढ़ने और समझने के लिहाज़ से। यह x86 assembly से भी ज़्यादा पेचीदा लगती है। CSS renderer के लिए एक तरह का pre-tokenized input है, लेकिन यह न तो सच में tokens जैसा है और न ही इंसानों के लिखने के लिए स्वाभाविक। RFC की ASN.1 की तरह इसे शायद "ऐसा नहीं करना चाहिए" वाले उदाहरण के रूप में इस्तेमाल करना चाहिए.

  • मुझे जानना है कि उन भाषाओं में declarative या domain-specific language कितनी हैं। CSS की assembly से तुलना ठीक नहीं है। CSS declarative है, assembly उसका उलटा। ज़्यादातर frontend developers भी imperative भाषा से CSS पर आते समय शुरू में संघर्ष करते हैं, लेकिन धीरे-धीरे बेहतर समझने लगते हैं। CSS की terminology और concepts का मूल कंप्यूटर विज्ञान से ज़्यादा design/publishing उद्योग में है। बहुत से developers CSS को किसी explicit command set की तरह देखते हैं, जबकि CSS चीज़ों के पारस्परिक प्रभाव वाली एक विचित्र प्रणाली है। एक property कभी-कभी पूरे layout algorithm को बदल देती है (CSS layout algorithm परिचय).
  • भले ही कोई कहे कि वह "15 भाषाएँ जानता है", CSS को सच में जानना बहुत कठिन है। बहुत-सी programming languages इस्तेमाल कर लेने से भी उस स्तर की समझ नहीं आती जहाँ आप कह सकें कि आप उसे वास्तव में जानते हैं; उसके लिए बहुत गहरा व्यावहारिक अनुभव चाहिए (व्याख्यात्मक गहराई का भ्रम wiki)। CSS को समझने का सबसे अच्छा तरीका है rendering result को सीधे देखना और उसका आकलन करना। मैं दशकों से यही करता आया हूँ.
  • मुझे भी HTML/CSS/JS की तिकड़ी में CSS सबसे कम पसंद है.
  • "CSS pre-tokenized input है" — इसका मतलब थोड़ा और विस्तार से सुनना चाहूँगा.
  • font-size: 12px जैसे code को तो काफ़ी आसानी से पढ़ा जा सकता है, इसलिए यह समझ नहीं आता कि यह इतना कठिन क्यों लगता है। मेरे लिए तो यह बहुत सरल है.

• मुझे जानना है कि radio tabs वाला उदाहरण accessibility के लिहाज़ से ठीक है या नहीं। WAI-ARIA के अनुसार, मेरा मानना है कि tab बदलते समय aria-selected, tabindex, और aria-controls attributes को JS से update करना चाहिए, लेकिन मैं निश्चित नहीं हूँ। accessibility को अक्सर बाद में सोचा जाता है। कभी-कभी लोग यह भी मान लेते हैं कि सिर्फ HTML/CSS इस्तेमाल करने से accessibility अपने-आप सुनिश्चित हो जाती है। किसी approach को चुनते समय इस पर एक बार और विचार होना चाहिए.

  • जहाँ तक मुझे पता है, ये radio tabs keyboard navigation और screen reader के साथ भी सही काम करते हैं, और WAI-ARIA example के tab-content flow का पालन करते हैं (WAI-ARIA उदाहरण)। accessibility की मेरी गहरी विशेषज्ञता नहीं है, लेकिन मैं जितना हो सके उतना सत्यापित करने की कोशिश कर रहा हूँ। मैंने कई accessibility tools से खुद test भी किए हैं.
  • मूल लेख में लेखक ने accessibility का कई बार ज़िक्र किया है, और browser bugs को भी workaround करने की कोशिश की है (संबंधित फुटनोट)।
  • इस blog post की अपनी accessibility, खासकर contrast, इतनी खराब है कि मैं, जो एक disability organization में web developer के रूप में काम करता हूँ, इसे reference material के तौर पर इस्तेमाल करना मुश्किल मानता हूँ.

• JS के बिना भी ऐसे interactive effects बनाए जा सकते हैं (उदाहरण पेज)

  • • गिरते हुए confetti animation
  • • close बटन वाला notification box
  • • notification बंद करने पर confetti भी साथ में गायब हो जाता है
  • • tabs भी काम करते हैं (हालाँकि इस उदाहरण में server reload की ज़रूरत है)
  • • JS जोड़ने पर animation और भी smooth और समृद्ध हो जाता है

• 10 साल के web developer के रूप में, मुझे लगता है कि ऐसे लेखों को हमारे भरोसे को चुनौती देनी चाहिए। शीर्षक इतना अच्छा नहीं था कि मैं लगभग इसे पढ़े बिना छोड़ देता। वैसे, सिर्फ CSS से map rendering नहीं हो सकती.

  • CSS+SVG का उपयोग करके map rendering की जा सकती है। हाँ, navigation जैसी अतिरिक्त सुविधाएँ अलग से implement करनी होंगी.

• शायद Vega नाम की वजह से लोगों के मन में पहले से धारणा हो, लेकिन मुझे यह site सच में बहुत पसंद आई। इसका overall design भी अच्छा है, और इस page की सामग्री भी शानदार है। मैं आगे से web development करने वाले लोगों को इसका लिंक ज़रूर साझा करूँगा। मुझे arrupted भी बहुत पसंद है, और इसने पहले भी बहुत शानदार काम किया है, इसलिए main page पर यह परिचित domain देखकर अच्छा लगा.