Tailwind से आगे बढ़ते हुए CSS को संरचित करना सीखना

• कुछ साइटों को Tailwind से semantic HTML और vanilla CSS में ले जाते हुए, Tailwind के दिए गए नियमों में से सिर्फ़ ज़रूरी हिस्सों को खुद दोबारा लागू किया गया
• Tailwind की preflight reset, color palette, font scale जैसे परिचित सिस्टम बनाए रखे गए, लेकिन उन्हें CSS variables और फ़ाइल विभाजन के साथ vanilla CSS में स्थानांतरित किया गया
• ज़्यादातर CSS को component-आधारित फ़ाइलों में बाँटा गया और हर component को unique class दी गई, ताकि एक component में बदलाव से दूसरे component के चुपचाप टूट जाने की संभावना कम हो
• Tailwind छोड़ने की वजहों में हाल के Tailwind की build system dependency, 2.8MB tailwind.min.css, vanilla CSS के साथ मिश्रित उपयोग, और CSS पर लगने वाली सीमाएँ शामिल हैं
• responsive design में breakpoint की बजाय CSS grid के auto-fit, grid-template-areas का ज़्यादा उपयोग करने की कोशिश है, और @layer, @scope, container queries को भी सीखने लायक विषय माना गया है

---

Tailwind से सीखी गई संरचना को vanilla CSS में लाना

• 8 साल पहले जब पहली बार Tailwind इस्तेमाल किया था, तब CSS कोड को कैसे संरचित करना है यह पता नहीं था, और पूरी अव्यवस्था की तुलना में Tailwind कहीं बेहतर विकल्प था
• हाल में लगभग एक हफ़्ते तक कुछ साइटों को Tailwind से semantic HTML + vanilla CSS में ले जाते हुए, Tailwind के दिए गए नियमों में से सिर्फ़ ज़रूरी हिस्सों को चुनकर खुद दोबारा लागू करना पड़ा
• A whole cascade of layers और How I write CSS in 2024 पढ़ते हुए यह और स्पष्ट हुआ कि हर CSS codebase में layout, font, color, common components जैसी अलग-अलग चिंताओं को संभालने के लिए कोई सिस्टम होना चाहिए
• Tailwind में reset stylesheet, color palette, font scale जैसे सिस्टम पहले से थे, और जो हिस्से परिचित व उपयोगी लगे उन्हें vanilla CSS में भी अपनाया जा सकता है

CSS codebase में रखे गए मुख्य सिस्टम

• 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;
    }
  

  • संदर्भ के रूप में the owl selector और “no outer margin” देखे गए

• 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;
  

  • grid-template-areas का भी खूब उपयोग किया गया, और इसे Tailwind में संभव नहीं मानी जाने वाली एक शानदार क्षमता माना गया
  • संदर्भ सामग्री के रूप में CSS Tricks का A responsive grid layout with no media queries देखा गया

• 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 से जुड़ी एक पोस्ट भी लिखी गई थी

Tailwind से दूर जाने की वजहें

• 2018 के बाद से Tailwind की build system dependency काफ़ी बढ़ गई है, और बिना build system के नया Tailwind इस्तेमाल करना लगभग असंभव लगता है, इसलिए कई सालों से Tailwind v2 इस्तेमाल किया जा रहा था
• बिना build system के Tailwind इस्तेमाल करने के विकल्प के रूप में litewind उपलब्ध लगता है
• Tailwind मूल रूप से build system के साथ इस्तेमाल किए जाने के लिए बना था, लेकिन व्यवहार में ऐसा नहीं किया गया, इसलिए कई projects में 2.8MB की tailwind.min.css फ़ाइल रह गई और यह थोड़ा अटपटा लगा
• पहली बार Tailwind इस्तेमाल करने के समय की तुलना में अब CSS कौशल बेहतर हो गया है
• Tailwind में अंततः सीमाएँ हैं, और जब CSS में कुछ अजीब या विशेष करना हो तो वह हमेशा संभव नहीं होता
• ऐसी सीमाएँ बहुत उपयोगी हो सकती हैं, और vanilla CSS में जाते समय Tailwind की कुछ सीमाएँ फिर से लागू भी की जा रही हैं, लेकिन अब सिर्फ़ वही सीमाएँ चुनकर रखनी हैं जो सच में ज़रूरी हों
• एक ही project के भीतर vanilla CSS और Tailwind मिले-जुले रूप में मौजूद साइटें बनने लगीं, और उनका maintenance सुखद नहीं था
• यह जानने की जिज्ञासा थी कि और अधिक semantic HTML लिखने का अनुभव कैसा होता है

आगे सीखने की इच्छा रखने वाली CSS सुविधाएँ

• @layer cascade layers को संभालने की सुविधा है; अभी इस्तेमाल नहीं की गई, लेकिन इसे सीखना है
• @scope components या किसी विशेष scope के भीतर styles को संभालने के लिए दिलचस्प लगती है
• container queries container-आधारित responsive design के लिए हैं और इन्हें सीखना है
• subgrid CSS grid से जुड़ी एक सुविधा है जो रुचि सूची में है

Tailwind को पूरी तरह खारिज न करने वाला निष्कर्ष

• अभी Tailwind से दूर जाया जा रहा है, लेकिन Tailwind इस्तेमाल शुरू करने के फैसले से अब भी संतोष है
• Tailwind इस्तेमाल करते हुए बहुत कुछ सीखा गया, और tailwind.min.css हटाने के बाद भी साइट के भीतर Tailwind के कुछ हिस्से इस्तेमाल होते रह सकते हैं
• wizardzines.com के CSS को मूल रूप से डिज़ाइन और लिखने वाली Melody Starling की वजह से साइट के शानदार और मज़ेदार हिस्से बने
• CSS पर काम करते समय CSS Tricks, Smashing Magazine आदि से बहुत से CSS लेख पढ़े गए, और CSS community द्वारा साझा की जाने वाली practices बहुत मददगार रहीं

[GN⁺]

Lobste.rs टिप्पणियाँ

• निजी प्रोजेक्ट्स में अब मैं लगभग कोई CSS/JavaScript framework इस्तेमाल नहीं करता
  क्योंकि अगर dependency ही नहीं होगी, तो supply chain vulnerability भी नहीं हो सकती। बेशक, vulnerability सिर्फ वही एक तरह की नहीं होती, लेकिन इससे मदद मिलती है

  • मैं भी काफ़ी हद तक plain HTML/CSS/JS पर लौट आया हूँ, और बस थोड़ा-बहुत वही जोड़कर इस्तेमाल करता हूँ जो मैंने खुद बनाया हो
    यह framework fatigue, npm audit overload, और LLM की वजह से implementation style पर दूसरों की राय की कम परवाह करने का मिला-जुला नतीजा है। जैसे, “तुम React और Tailwind क्यों नहीं इस्तेमाल करते?” जैसे सवाल

• यह बस CSS के काम करने का तरीका है
  जब लोग यह जाने बिना Tailwind को अंधाधुंध इस्तेमाल करते हैं, तो बाहर जाकर बादलों पर चिल्लाने का मन करता है। मेरी नज़र में Tailwind का 90% बस अलग syntax वाला inline style है, और ज़्यादा से ज़्यादा <FONT> tag से एक कदम बेहतर कहा जा सकता है

  • इस टिप्पणी का मकसद क्या है, यह समझ नहीं आता, लेकिन करीब 8 साल से Tailwind इस्तेमाल करते हुए मैंने Tailwind users को नीचा दिखाने वाली ऐसी टिप्पणियाँ अनगिनत बार देखी हैं, और उनमें से किसी ने भी Tailwind छोड़ने या CSS skill बढ़ाने में मदद नहीं की
    यह ब्लॉग पोस्ट उन बातों को समझाती है जिन्हें मुझे सच में जानने की ज़रूरत थी
  • “Tailwind का 90% बस अलग syntax वाला inline style है” — यह बात ज़्यादा सटीक नहीं है
    Tailwind, inline style से काफ़ी अलग तरीके से काम करता है, और बल्कि CSS के कहीं ज़्यादा क़रीब है। जैसा कि लेख में भी कहा गया है, Tailwind को अच्छी तरह इस्तेमाल करने वाली कई अच्छी आदतें effective CSS लिखने के लिए भी ज़रूरी होती हैं। Tailwind, हर element पर implicit scope वाला CSS block लगाने जैसा है, बस एक अनोखी DSL के साथ
  • CSS कैसे काम करता है यह जानना और उसे प्रभावी ढंग से इस्तेमाल करना जानना — दोनों में बड़ा फ़र्क है
    मुझे 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 जोड़ देती है