-
reset
- Tailwind की preflight styles को
tailwind.css से शुरू में लगभग 200 पंक्तियाँ कॉपी करके इस्तेमाल किया गया
- Tailwind reset की आदत लंबे समय से थी, और सभी elements पर
box-sizing: border-box लगाने वाला नियम element की चौड़ाई में padding को शामिल कर देता है
* { box-sizing: border-box; }
- संभव है कि
html {line-height: 1.5;} जैसे दूसरे reset नियमों पर भी अनजाने में निर्भरता हो, और इन नियमों के बिना CSS लिखने के लिए काफ़ी बड़े अनुकूलन की ज़रूरत पड़ेगी
-
components
- ज़्यादातर CSS को Vue या React components की तरह component-आधारित फ़ाइलों में व्यवस्थित किया गया
- हर component की अपनी unique class होती है, और इस तरह बनाया जाता है कि एक component का CSS दूसरे component के CSS को overwrite न करे
- वास्तव में बदला जाने वाला लगभग 80% CSS component फ़ाइलों के अंदर ही होता है, इसलिए 100 पंक्तियों वाले component को संपादित करते समय सिर्फ़ उन्हीं 100 पंक्तियों के बारे में सोचना पड़ता है
- उदाहरण के लिए
.zine component का HTML कुछ ऐसा हो सकता है
<figure class="zine horizontal">
<img src="whatever.jpg">
</figure>
- CSS में nested selectors का उपयोग करके
.horizontal, .vertical, :hover जैसी अवस्थाओं को component के भीतर रखा जाता है
.zine {
...
&.horizontal {
...
}
&.vertical {
...
}
&:hover {
...
}
}
- Web Components या
@scope की तरह components के बीच हस्तक्षेप को प्रोग्रामेटिक तरीके से नहीं रोका गया, लेकिन सिर्फ़ conventions तय करके उनका पालन करना भी काफ़ी सुधार जैसा लगा
-
colours
colours.css में ज़रूरत पड़ने पर इस्तेमाल किए जा सकने वाले CSS variables इकट्ठे रखे गए- colors मुश्किल होते हैं, और इस refactoring में color usage को फिर से परखना नहीं चाहा गया, इसलिए मौजूदा तरीका बनाए रखा गया
- एकमात्र नियम यह है कि साइट में इस्तेमाल होने वाले सभी colors इस फ़ाइल में सूचीबद्ध हों
:root {
--pink: #fea0c2;
--pink-light: #F9B9B9;
--red: #f91a55;
--orange: rgb(222, 117, 31);
...
}
-
font sizes
- Tailwind में
text-lg, xl, 2xl जैसी size steps चुनना काफ़ी था, इसलिए em, px, rem में क्या इस्तेमाल हो रहा है यह याद रखने की ज़रूरत नहीं पड़ती थी
- इसे vanilla CSS में भी बनाए रखने के लिए Tailwind से लिए गए size variables परिभाषित किए गए
--size-xs: 0.75rem;
--line-height-xs: 1rem;
--size-sm: 0.875rem;
--line-height-sm: 1.25rem;
- font size को variables से सेट किया जाता है, और भले ही यह Tailwind से थोड़ा ज़्यादा verbose हो, फिलहाल यह संतोषजनक तरीका लगता है
h3 {
font-size: var(--size-lg);
line-weight: var(--line-weight-lg);
}
-
utilities
- कई components में दोहराए जाने वाले elements, जैसे buttons, को utilities के रूप में वर्गीकृत किया गया
.sr-only जैसी कुछ utility classes, जो सिर्फ़ screen reader users को दिखने वाले elements के लिए होती हैं, Tailwind से कॉपी की गईं- इस हिस्से को छोटा रखने और बदलते समय सावधानी बरतने की कोशिश है
-
base
- “base” styles वे styles हैं जो सीधे पूरी साइट पर लागू होते हैं
- पूरी साइट पर बहुत सारे styles थोपने को लेकर पर्याप्त भरोसा नहीं है, इसलिए इस हिस्से को बहुत छोटा रखा गया है
- अभी जो नियम ठीक लगते हैं वे सिर्फ़
<section> और a के लिए हैं, और <section> वाला नियम बाद में बदल सकता है
/* put a 950px column in the middle of each <section> */
section {
--inner-width: 950px;
padding: 3rem max(1rem, (100% - var(--inner-width))/2);
}
a {
color: var(--orange);
}
- base styles को शुरुआत में लगभग खाली रखना, और जब कुछ सचमुच common लगे तो उसे component से base में ले आना, एक bottom-up तरीका है जो सबसे आसान लगता है
-
spacing
- padding और margin को संभालने का तरीका अभी पूरी तरह तय नहीं हुआ है
- Tailwind इस्तेमाल करते समय मनचाहा रूप आने तक padding और margin को इधर-उधर तुरंत जोड़ दिया जाता था, और अब उससे थोड़ा ज़्यादा सिद्धांत-आधारित तरीका खोजा जा रहा है
- फिलहाल कोशिश है कि जहाँ तक संभव हो, बाहरी layout components spacing की ज़िम्मेदारी लें
- अगर कई children वाले
<section> में बच्चों के बीच बराबर spacing चाहिए, तो यह नियम इस्तेमाल किया जा सकता है
section > *+* {
margin-top: 1rem;
}
-
responsive design
- Tailwind में
md:text-xl जैसे media query-आधारित syntax का बहुत उपयोग था, जहाँ किसी खास size से ऊपर text-xl style लागू होता था
- अब कोशिश है कि कम breakpoints के साथ भी काम करने वाले, ज़्यादा flexible CSS grid layouts बनाए जाएँ
auto-fit इस्तेमाल करने पर बड़ी स्क्रीन पर 2 columns और छोटी स्क्रीन पर 1 column अपने-आप इस्तेमाल हो सकता है
display: grid;
grid-template-columns: repeat(auto-fit, minmax(min(100%, 400px), max-content));
justify-content: center;
-
build system
- development के दौरान अलग build system की ज़रूरत नहीं पड़ती
- CSS में built-in
@import statement है, जिससे फ़ाइलों को बाँटकर लाया जा सकता है
@import "reset.css";
@import "typography.css";
@import "colors.css";
- CSS में nested selectors भी built-in हैं
.page {
h2 { ...}
}
- अगर production के लिए CSS फ़ाइलों को bundle करना हो, तो
esbuild इस्तेमाल किया जा सकता है
esbuild style.css --bundle --loader:.svg=dataurl --loader:.woff2=file --outfile=/tmp/out.css
- आम तौर पर CSS और JS build systems के उपयोग से बचा जाता है, लेकिन
esbuild web standards पर आधारित है और static Go binary है, इसलिए यह स्वीकार्य लगता है
esbuild पर 2021 में esbuild और Vue से जुड़ी एक पोस्ट भी लिखी गई थी
3 टिप्पणियां
zero-configमें बदलने के बाद क्या यह थोड़ा बेहतर नहीं हो गया है?Hacker News की राय
मैंने लंबे समय तक semantic HTML और accessible markup सिखाया है, और screen reader के लिए साइट्स और ऐप्स पर भी बहुत काम किया है। Tailwind की सबसे बड़ी समस्या यह है कि यह HTML और CSS के बारे में सोचने का क्रम उलट देता है
HTML का काम दस्तावेज़ का अर्थ बताना है, इसलिए शुरुआत वहीं से होनी चाहिए, और उसके बाद CSS से styling करनी चाहिए। अगर styling की वजह से अतिरिक्त elements चाहिए हों तो
divयाspanका इस्तेमाल किया जा सकता है, लेकिन पहले यह सोचना चाहिए कि क्या कोई बेहतर element मौजूद हैTailwind developers को CSS-first approach की ओर धकेलता है, जिससे वे पहले मनचाही Tailwind classes के बारे में सोचते हैं और फिर उन classes को लगाने के लिए DOM में एक और
divजोड़ देते हैंएक web developer की क्षमता में ऐसे HTML और CSS बनाना शामिल होना चाहिए जो भविष्य में भी पढ़ने योग्य हों, सभी users के लिए उपयोगी हों, और बड़े पैमाने पर HTML/CSS specs के अनुरूप हों। Tailwind इस मामले में कौशल को कमजोर करता है। Tailwind वेबसाइट के पहले example में भी सिर्फ
divऔरspanहैं, इसने नए developers को खराब training दी है, और मुझे लगता है कि इसने उस प्रवृत्ति में भी योगदान दिया है जहाँ LLM बिना अलग निर्देश के div soup उगल देते हैंकिसी भी tool का गलत इस्तेमाल हो सकता है, Tailwind भी इसका अपवाद नहीं है। मैंने लगभग 20 साल CSS इस्तेमाल किया है, और Less, SASS/SCSS, Stylus, PostCSS भी आज़माए हैं, लेकिन पिछले कुछ वर्षों में Tailwind पर टिकने का कारण यह है कि यह वास्तव में अधिक robust application styling संभव बनाता है
style/class abstraction को ज़रूरत से ज़्यादा बढ़ाना नहीं पड़ता, और styles को सीधे उसी markup के पास रखने से जिस पर उनका असर पड़ता है, cognitive load कम होता है। loose selectors के कारण अनजाने में styles बदलने की घटनाएँ भी कम होती हैं और debugging आसान हो जाती है। साधारण sites/apps को छोड़कर, custom CSS framework वाले codebases की तुलना में Tailwind codebases अक्सर कम जटिल और कम fragile होते हैं
consistent fonts, colors, और size scales, छोटे bundles, Tailwind जानने वाले developers के बीच consistency, मजबूत ecosystem, और LLM familiarity—इन सबको देखते हुए यह कई teams के लिए शानदार विकल्प है। आखिरकार ज़्यादातर tools की तरह, यह भी इस पर निर्भर करता है कि इसे कौन और कैसे इस्तेमाल करता है
HTML/CSS/JS की अव्यवस्था को मैं browser के लिए काम करते समय एक आवश्यक बुराई मानता हूँ, और मेरे लिए यह बस एक presentation layer है। काम में मैं database schema या backend business logic की correctness पर कहीं ज़्यादा ध्यान देता हूँ
अगर एक गंदी presentation layer को यथासंभव कम इस्तेमाल करते हुए भी कुछ हद तक maintainable code मिल जाए, तो मेरे लिए इतना काफी है, और उस उद्देश्य के लिए Tailwind अच्छी तरह फिट बैठता है। LLM इसे अच्छी तरह लिखते हैं, नए developers इसे जल्दी समझ लेते हैं, और बाद में पढ़ना और बदलना भी काफ़ी आसान होता है
मैं इस बात से पूरी तरह सहमत हूँ कि Tailwind project नए developers के लिए HTML/CSS सीखने का सबसे अच्छा तरीका नहीं है, लेकिन मैं फिर भी चाहूँगा कि नए developers अच्छा database schema, intuitive API, testable business logic जैसी चीज़ों पर ज़्यादा ध्यान दें
Tailwind में ऐसा कुछ भी नहीं है जो आपको उचित HTML tags की जगह
divऔरspanइस्तेमाल करने के लिए मजबूर करेdocuments और interfaces अलग चीज़ें हैं, और Tailwind interfaces में कहीं ज़्यादा समझ में आता है। Interfaces में Tailwind इस्तेमाल किया जा सकता है, और दूसरे content के लिए scoped HTML selectors इस्तेमाल किए जा सकते हैं
जटिल CSS codebase लिखने की तुलना में Tailwind लगभग 4 गुना तेज़ है और इसमें व्यावहारिक रूप से कोई overhead नहीं है—यह किसी भी evaluation में एक फायदा बना रहता है
संक्षेप में, यह CSS को specificity के क्रम में लिखने का तरीका है:
/scss/
├── 1-settings. <- global settings
├── 2-design-tokens <- fonts, colors, spacing आदि
├── 3-tools <- Sass mixins, CSS functions आदि
├── 4-generic <- reset, box sizing, normalize आदि
├── 5-elements <- headings, buttons, links की default styles
├── 6-skeleton <- layout grids आदि
├── 7-components <- cards, carousel आदि
├── 8-utilities <- utility और helper classes
├── _shame.scss <- बाद में ठीक किए जाने वाले hacks
└── main.scss
ITCSS CSS codebase में specificity wars को लगभग खत्म कर देता है। आम तौर पर
!importantसिर्फ utility layer में ही आता है[1]: https://matthiasott.com/notes/how-i-structure-my-css
component libraries देखें तो वे
ariaattributes भी शामिल करते हैं: https://tailwindcss.com/plus/ui-blocks/marketing/sections/pr...जब तक चीज़ किसी landing page जैसी digital brochure न हो, मैं हमेशा markup से शुरू करता हूँ और उसके ऊपर CSS classes जोड़ता हूँ
Tailwind की दो अच्छी बातें हैं: AI training data में class information पहले से बहुत है, और style conflicts नहीं होते
इसलिए जब AI नए styles बनाता है, तो उसे existing stylesheet देखने की ज़रूरत नहीं पड़ती, जो context management के लिए अच्छा है
custom CSS में conflicts या duplication कम करने के लिए AI को existing stylesheet पढ़नी पड़ती है, लेकिन बड़े stylesheets AI की memory space का बहुत हिस्सा ले सकते हैं, जो समस्या बन सकता है
मुझे Julia Evans की लिखाई सच में बहुत पसंद है
वह vulnerability और honesty की जगह से लिखती हैं। बहुत से लोग smart दिखने के लिए लिखते हैं, लेकिन Julia इस भाव से लिखती हैं: “मुझे भी सब कुछ नहीं पता, लेकिन जो मैंने खोजा है उसमें कुछ ऐसा है जिसे मैं साझा करना चाहती हूँ।” ऐसा लगता है जैसे वह उन लोगों के साथ कुछ बाँट रही हों जिन्हें वह प्यार करती हैं, भले मैं उन्हें व्यक्तिगत रूप से न जानता होऊँ
पिछली Strange Loop में उन्होंने Randall Munroe के साथ प्रस्तुति दी थी। प्रस्तुति के बाद कुछ लोग उनसे बात करने के लिए इंतज़ार कर रहे थे, लेकिन मैं Julia से बात करने के लिए रुका था। मुझे सच में अफ़सोस है कि शायद वह bash script को Perl में फिर से लिखने वाला मेरा मज़ाक समझ नहीं पाईं
मैं Julia नहीं हूँ, लेकिन सार्वजनिक talks या presentations के बारे में मेरी लगभग यही philosophy है, और मैं इसे उन सहकर्मियों में भी डालने की कोशिश करता रहा हूँ जो presentation देने में कठिनाई महसूस करते हैं। अपने साथियों और प्रियजनों को वह ज्ञान देना, जिससे मैं थोड़ा अधिक परिचित हूँ और जो उनके लिए उपयोगी हो सकता है, अपने आप में एक बड़ा privilege है
CSS Modules cascading problem का एक सरल समाधान है। यह unique class names बनाकर class conflicts को रोकता है [1]
इसमें Tailwind की दो बड़ी कमियाँ नहीं हैं: readability [2] और tool support की कमी। खासकर Chrome और FireFox DevTools में debugging और interactive experimentation के लिए इसका tool support बेहतर लगता है
[1] https://x.com/efortis/status/1888304658080256099
[2] https://github.com/ericfortis/tailwind-eye
Tailwind के बारे में जो बात मुझे हमेशा प्रभावशाली लगी, वह यह है कि इसके समर्थकों के लगभग सभी तर्क आखिरकार इसी पर आ टिकते हैं कि “उन्होंने कभी CSS को junior स्तर से ऊपर सीखा ही नहीं”
अक्सर सुनने को मिलता है: “Tailwind के बिना एक बड़ा, बेतरतीब CSS file नियंत्रण से बाहर बढ़ता जाएगा, और पुराने code तथा
!importantसे भर जाएगा।” लेकिन CSS भी बाकी technical skills की तरह एक skill ही हैअगर आप सिर्फ इतना सीखते हैं कि चीज़ें देखने में सही लगें और फिर patchwork करते रहते हैं, तो बहुत जल्दी आपकी महत्वाकांक्षा आपके code को व्यवस्थित रखने की क्षमता से आगे निकल जाएगी
Tailwind और CSS पर बात करते हुए जब यह एहसास हो कि सामने वाले को “cascading” का मतलब ही नहीं पता, और उसने कभी यह सोचा तक नहीं कि stylesheet context में यह concept उपयोगी भी हो सकता है, तो सच में बहुत झुंझलाहट होती है
मैंने 90 के दशक से CSS का बहुत इस्तेमाल किया है, Tailwind को भी देखा, और समझने के बाद अब अधिकांशतः pure CSS से बचता हूँ। एक अर्थ में यह एक अव्यवस्था को दूसरी अव्यवस्था से बदलना है, लेकिन व्यक्तिगत रूप से मुझे कई files में फैले overlapping और contradictory cascades की तुलना में localized class soup संभालना बेहतर लगता है
दोनों को साफ-सुथरे तरीके से implement किया जा सकता है, लेकिन Tailwind की अव्यवस्था को साफ करना CSS की अव्यवस्था से कहीं बेहतर है, और पूरा development process भी ज़्यादा सुखद लगता है
मैं खुद 20 साल से ज़्यादा समय से programming कर रहा हूँ और लगभग 15 साल से web development भी, लेकिन CSS को ठीक से सीखने की प्रेरणा मिलना कठिन है। बहुत सारी technical skills के साथ बने रहना पड़ता है, और CSS मेरी priorities में काफ़ी नीचे है
मैं इसे किसी विशेषज्ञ पर छोड़ना पसंद करूँगा, लेकिन कंपनियाँ dedicated frontend developers रखना नहीं चाहतीं
मैं scalable HTML और CSS लिखने पर केंद्रित एक साफ-सुथरी web development guide लिख रहा हूँ: https://webdev.bryanhogan.com/
शायद यहाँ के लोगों के लिए उपयोगी हो। Styling के लिए Tailwind जैसी किसी चीज़ का उपयोग नहीं करता, सिर्फ Astro या Svelte जैसे modern frameworks और CSS का इस्तेमाल करता हूँ
हर project में
reset.css,var.css,global.css,util.cssरखता हूँ, और बाकी styles को उनके component या layout तक सीमित रखता हूँअच्छा लेख है
मुझे external library dependencies हटाना और शुरुआत से अपने solutions बनाना पसंद है, लेकिन Tailwind में ऐसा न करने का एक साफ कारण है। यह production optimization देता है, जिससे यह सुनिश्चित होता है कि वास्तव में सिर्फ न्यूनतम CSS ही deploy हो
भले ही आप
globals.cssया कहीं और colors, spacing जैसी सभी options सूचीबद्ध कर दें, production में आपको यह चिंता नहीं करनी पड़ती कि उन variants में से सभी उपयोग हो रहे हैं या नहीं। Next.js जैसे framework में काम करने पर build के समय यह minimization step अपने-आप हो जाता है, और केवल यही बात Tailwind से न हटने के लिए पर्याप्त कारण बन जाती हैTailwind में inline CSS इस्तेमाल करते समय मैंने कभी ऐसे constraints महसूस नहीं किए जिन्हें संभालना मुश्किल हो, और Tailwind के grid tools के साथ screen width के हिसाब से responsive grids लागू करने में भी कोई बड़ी दिक्कत नहीं हुई। लेख में आए सभी scenarios मैंने या तो Tailwind से, या Tailwind+CSS के संयोजन से हल किए हैं। यह सच है कि
grid-column-areasbuilt-in नहीं है, लेकिन responsive grid layouts में इसे मैंने अब तक कोई बड़ी सीमा नहीं मानाTailwind की सबसे बड़ी समस्या यह है कि इसे पढ़ने की आदत डालने में समय लगता है। हमें इस तरह सिखाया गया है कि inline CSS बुरा है और globally scoped CSS अच्छा, और हम साफ HTML के आदी हैं। इसलिए असली Tailwind code, खासकर लंबी lines, शुरुआत में सच में पढ़ने में कठिन लगती हैं। लंबे समय तक इस्तेमाल करने के बाद मैं इसकी शक्ल का पूरी तरह अभ्यस्त हो गया, और आखिरकार मेरे लिए निष्कर्ष यह निकला कि Tailwind अधिक efficient, अधिक maintainable, और यहाँ तक कि अधिक readable भी है—लेकिन इसमें समय लगा
इन दिनों मुझे जो approach सच में पसंद आ रही है, वह है Tailwind और scoped styles को साथ में इस्तेमाल करना (Svelte और Vue में)
इससे Tailwind की सुविधा बनी रहती है और template pollution कम से कम होता है:
+
{{ count }}
मेरे लिए Svelte और LLM ने Tailwind की ज़रूरत पूरी तरह खत्म कर दी
बाद में समझ आया कि मैं Tailwind मुख्यतः self-imposed constraints की वजह से नहीं, बल्कि CSS conflicts से बचने और उस syntax की वजह से इस्तेमाल कर रहा था जो मुझे ज़्यादा logical लगती थी
Tailwind की सबसे अच्छी बात यह है कि आपको अस्थायी class names गढ़ने की ज़रूरत नहीं पड़ती। अब BEM का इस्तेमाल नहीं करना पड़ता
Lobste.rs टिप्पणियाँ
निजी प्रोजेक्ट्स में अब मैं लगभग कोई CSS/JavaScript framework इस्तेमाल नहीं करता
क्योंकि अगर dependency ही नहीं होगी, तो supply chain vulnerability भी नहीं हो सकती। बेशक, vulnerability सिर्फ वही एक तरह की नहीं होती, लेकिन इससे मदद मिलती है
यह framework fatigue,
npm auditoverload, और LLM की वजह से implementation style पर दूसरों की राय की कम परवाह करने का मिला-जुला नतीजा है। जैसे, “तुम React और Tailwind क्यों नहीं इस्तेमाल करते?” जैसे सवालयह बस CSS के काम करने का तरीका है
जब लोग यह जाने बिना Tailwind को अंधाधुंध इस्तेमाल करते हैं, तो बाहर जाकर बादलों पर चिल्लाने का मन करता है। मेरी नज़र में Tailwind का 90% बस अलग syntax वाला inline style है, और ज़्यादा से ज़्यादा
<FONT>tag से एक कदम बेहतर कहा जा सकता हैयह ब्लॉग पोस्ट उन बातों को समझाती है जिन्हें मुझे सच में जानने की ज़रूरत थी
Tailwind, inline style से काफ़ी अलग तरीके से काम करता है, और बल्कि CSS के कहीं ज़्यादा क़रीब है। जैसा कि लेख में भी कहा गया है, Tailwind को अच्छी तरह इस्तेमाल करने वाली कई अच्छी आदतें effective CSS लिखने के लिए भी ज़रूरी होती हैं। Tailwind, हर element पर implicit scope वाला CSS block लगाने जैसा है, बस एक अनोखी DSL के साथ
मुझे CSS के काम करने का तरीका अच्छी तरह पता है, लेकिन plain CSS अब भी भारी लगता है और graphic design में भी मैं कमज़ोर हूँ, इसलिए अभी भी Tailwind इस्तेमाल करता हूँ। यह लेख Tailwind के आधार पर CSS को संरचित करने के ideas देता है
जो लोग हाल की दिशा को ठीक से follow नहीं कर पाए हैं, उनके नज़रिए से यह लेख modern CSS practices को काफ़ी अच्छी तरह दिखाता है
मुझे यह भी अच्छा लगा कि इसमें प्रेरित करने वाले लेखों तक जाने वाले बहुत से links हैं। पढ़ने लायक सामग्री लगती है, और अभी तक मैंने सिर्फ "no outer margin" पढ़ा है
हालाँकि, base styles को “नीचे से ऊपर” बनाने वाले approach को लेकर मैं थोड़ा सशंकित हूँ। इसके बजाय क्या करना चाहिए, यह नहीं पता, और यह आज़माने लायक ज़रूर लगता है, लेकिन base styles अपने आप में काफ़ी पेचीदा होते हैं
यह लेख मुझे सच में बहुत अच्छा लगा
मैंने भी बहुत सी छोटी sites बनाते-बनाते धीरे-धीरे CSS सीखी, और अगर शुरू से ही इस तरह की systematic thinking ज़्यादा होती, तो शायद मदद मिलती। frameworks को लेकर मुझमें काफ़ी झिझक रही है, लेकिन उन्हें इस्तेमाल न करने की वजह से, अपनी मनचाही चीज़ बना लेने के बाद भी अक्सर ऐसा लगता है जैसे सब कुछ बिना संरचना के हवा में तैर रहा हो
यह बात अच्छी लगी कि लहजा “Tailwind बेकार है, बस CSS इस्तेमाल करो” वाला नहीं है, बल्कि “Tailwind शानदार है, लेकिन अब शायद उसकी ज़रूरत न हो” वाला है
मुझे CSS को हाथ से संरचित करने में हमेशा दिक्कत हुई है, लेकिन इस लेख की वजह से अब मैं इसे बिल्कुल अलग तरीके से सोच रहा हूँ
CSS को व्यवस्थित करते समय यह structuring technique काफ़ी उपयोगी रही: https://rstacruz.github.io/rscss/
कुल मिलाकर, यह मूल लेख में jvns द्वारा समझाई गई बातों से अच्छी तरह मेल खाती है, और उसके ऊपर थोड़ी और structure और organization जोड़ देती है