CSS लेआउट का इतिहास: टेबल से ग्रिड तक — 2026 में क्या उपयोग करें

हर कुछ वर्षों में CSS में लेआउट करने का “सही” तरीका पूरी तरह बदल जाता है। अगर आपने 2015 से पहले CSS लिखना शुरू किया था, तो शायद हर बार जब कोई clearfix का उल्लेख करता है तो आपको एक हल्का आघात महसूस होता है। आइए मैं आपको बताता हूँ कि हम यहाँ तक कैसे पहुँचे — और 2026 में आपको वास्तव में किस चीज़ का उपयोग करना चाहिए।

टेबल का युग (1990 के दशक – 2000 के दशक के मध्य)

HTML टेबल कभी भी लेआउट के लिए नहीं बनाई गई थीं। वे टेबुलर डेटा प्रदर्शित करने के लिए मौजूद थीं। फिर वेब डिज़ाइनरों ने खोजा कि <table>, <tr>, और <td> आपको कुछ ऐसा देते हैं जो CSS अभी तक प्रदान नहीं कर सकती थी: पूर्वानुमानित कॉलम नियंत्रण [1]।

तो पूरा वेब नेस्टेड टेबल के साथ बनाया गया था। सिर्फ एक परत गहरा नहीं — बहु-स्तरीय नेस्टिंग, टेबल के अंदर टेबल के अंदर टेबल। और स्पेसिंग नियंत्रित करने के लिए? एक पारदर्शी 1×1 पिक्सेल GIF इमेज (spacer.gif) जिसमें एक स्पष्ट width एट्रीब्यूट था [2]। मैं मज़ाक नहीं कर रहा। यही तकनीक थी।

यह काम किया क्योंकि यह सुसंगत था। 90 के दशक के उत्तरार्ध में CSS सपोर्ट हास्यास्पद रूप से असंगत था। Internet Explorer और Netscape एक ही CSS को अलग-अलग तरह से रेंडर करते थे। टेबल हर जगह एक जैसी रेंडर होती थी। पूर्वानुमेयता जीती। [3]

टेबल कभी भी लेआउट के लिए नहीं थीं। यह तथ्य कि वे डिफ़ॉल्ट बन गईं, पूरी तरह से ब्राउज़र असंगतता की एक दुर्घटना थी।

2000 के दशक की शुरुआत तक, जब CSS सपोर्ट परिपक्व हुई और “सेपरेशन ऑफ कंसर्न्स” मुख्यधारा की सोच बन गई, समुदाय ने सामूहिक रूप से आगे बढ़ने का फैसला किया। सिवाय उस कोडबेस के जो आपकी कंपनी 2004 से मेंटेन कर रही है — उसमें अभी भी टेबल हैं।

फ्लोट का युग (2000 के दशक की शुरुआत – ~2012)

CSS float को किसी इमेज के चारों ओर टेक्स्ट लपेटने के लिए डिज़ाइन किया गया था — एक अखबार की फोटो की तरह जिसके चारों ओर टेक्स्ट बह रहा हो। बस इतना। यही इसका इच्छित उपयोग था [4]।

किसी ने पता लगाया कि अगर आप कई <div> एलीमेंट को बाईं ओर फ्लोट करते हैं, तो वे साथ-साथ बैठते हैं। मल्टी-कॉलम लेआउट प्राप्त हुआ। और इस तरह पूरा वेब टेबल हैक्स से फ्लोट हैक्स में स्थानांतरित हो गया।

समस्याएँ तत्काल थीं:

एक फ्लोटेड एलीमेंट दस्तावेज़ प्रवाह से हटा दिया जाता है, इसलिए पैरेंट कंटेनर ढह जाता है
इसे ठीक करने के लिए आपको overflow: hidden या खाली <div class="clear"></div> एलीमेंट जोड़ने पड़ते थे
प्रसिद्ध clearfix हैक — एक CSS छद्म-एलीमेंट ट्रिक — एक मानक कॉपी-पेस्ट स्निपेट बन गया जो हर डेवलपर अपने पास रखता था [4]

/* The clearfix hack — you've seen this a thousand times */
.clearfix::after {
  content: "";
  display: block;
  clear: both;
}

inline-block का भी उपयोग हुआ, क्षैतिज नेविगेशन आइटम के लिए। यह एक हद तक काम करता था जब तक आपको व्हाइटस्पेस समस्या का पता नहीं चलता था — आपके HTML टैग के बीच कोई भी स्पेस या न्यूलाइन एलीमेंट के बीच एक दृश्यमान अंतर के रूप में रेंडर होती थी। “ठीक” करने का तरीका था अपने समापन </li> को अगले आइटम के शुरुआती <li> के साथ एक ही लाइन पर रखना। वास्तव में दयनीय।

यह युग जितना चाहिए था उससे ज़्यादा लंबा चला, ज़्यादातर इसलिए क्योंकि विकल्पों के लिए ब्राउज़र सपोर्ट धीमा था।

Flexbox (2012 – वर्तमान)

CSS वर्किंग ग्रुप ने 2008 में Flex लेआउट मॉडल प्रस्तावित किया, 2009 में पहला वर्किंग ड्राफ्ट प्रकाशित किया, और फिर float/table/inline-block हैक्स पर निर्भरता हटाने के लिए 2011 में पूरी स्पेक को फिर से लिखा [1]।

display: flex लगभग 2012 के आसपास ब्राउज़र में शिप होना शुरू हुआ। वेंडर प्रीफिक्स की जुगलबंदी के बिना प्रोडक्शन के लिए सुरक्षित होने में ~2014-2015 तक का समय लगा।

Flexbox ने वास्तव में क्या हल किया:

वर्टिकल सेंटरिंग — आखिरकार। इसी एक चीज़ ने माइग्रेशन को उचित ठहराया।
गैप नियंत्रण के साथ एक-अक्ष आइटम संरेखण
आइटम जो उपलब्ध स्थान भरने के लिए आनुपातिक रूप से बढ़ते और सिकुड़ते हैं
HTML को छुए बिना क्रम उलटना

.nav {
  display: flex;
  align-items: center;
  gap: 1rem;
}

यह एक नेविगेशन बार है। कोई float नहीं। कोई clearfix नहीं। कोई spacer GIF नहीं। बस काम करता है।

लेकिन Flexbox एक-आयामी है। यह एक पंक्ति या एक कॉलम संभालता है — दोनों एक साथ नहीं। केवल Flexbox का उपयोग करके हेडर, साइडबार, कंटेंट और फुटर के साथ एक पेज लेआउट बनाने की कोशिश करें और आप देखेंगे कि मेरा मतलब क्या है। आप flex कंटेनर के अंदर flex कंटेनर नेस्ट करते रहते हैं, और यह जल्दी ही अव्यवस्थित हो जाता है।

CSS Grid (2017 – वर्तमान)

यह Microsoft से आया। Microsoft के इंजीनियर अपने ब्राउज़र के लिए एक उचित लेआउट सिस्टम चाहते थे और 2012 में W3C को एक Grid Layout प्रस्ताव सबमिट किया। उन्होंने उस वर्ष -ms- वेंडर प्रीफिक्स का उपयोग करके IE10 में एक implementation शिप किया [1]।

स्पेक वर्षों तक परिष्कृत होती रही। 2017 में, Chrome, Firefox, और Safari ने सभी ने एक दुर्लभ समन्वित रिलीज़ में एक-दूसरे के कुछ हफ्तों के भीतर CSS Grid शिप किया। यह वास्तव में एक बड़ा क्षण था।

CSS Grid दो-आयामी है। पंक्तियाँ और कॉलम एक साथ।

.page {
  display: grid;
  grid-template-areas:
    "header header"
    "sidebar content"
    "footer footer";
  grid-template-columns: 250px 1fr;
}

यह छह लाइनों में आपका पूरा पेज लेआउट है। कोई फ्लोट नहीं। कोई clearfix नहीं। कोई नेस्टेड बकवास नहीं।

css layout timeline

Subgrid और Container Queries (2023 – वर्तमान)

ये दो फीचर वर्तमान अग्रणी हैं। दोनों अब प्रोडक्शन में उपयोग के लिए सुरक्षित हैं।

Subgrid

क्लासिक Grid समस्या: आपके पास कार्ड का एक ग्रिड है। प्रत्येक कार्ड में एक शीर्षक, बॉडी टेक्स्ट और एक बटन है। शीर्षकों की अलग-अलग लंबाई होती है। प्रत्येक कार्ड के बटन अलग-अलग वर्टिकल पोज़ीशन पर समाप्त होते हैं। आप JavaScript हैक्स के बिना उन्हें कार्ड के पार संरेखित नहीं कर सकते — क्योंकि प्रत्येक कार्ड अपना खुद का stacking context है।

Subgrid इसे ठीक करता है। एक चाइल्ड एलीमेंट पैरेंट ग्रिड की ट्रैक साइज़िंग इनहेरिट कर सकता है। [5]

.card-grid {
  display: grid;
  grid-template-rows: auto 1fr auto; /* title / body / button */
}

.card {
  display: grid;
  grid-row: span 3;
  grid-template-rows: subgrid; /* inherits parent tracks */
}

अब हर बटन संरेखित है। कोई JavaScript नहीं। कोई position: absolute कलाबाजी नहीं।

2026 तक ब्राउज़र सपोर्ट: वैश्विक स्तर पर 97%+ [6]। Firefox ने इसे 2019 में, Safari ने 2022 में, Chrome 117 ने सितंबर 2023 में शिप किया। यह हो गया — इसका उपयोग करें।

Container Queries

मीडिया क्वेरी व्यूपोर्ट का जवाब देती हैं। Container queries पैरेंट कंटेनर का जवाब देती हैं। यह बहुत मायने रखता है जब एक ही कंपोनेंट साइडबार में और मुख्य सामग्री क्षेत्र में दिखाई देता है।

.card-container {
  container-type: inline-size;
}

@container (min-width: 400px) {
  .card {
    flex-direction: row;
  }
}

Container queries अब सभी प्रमुख ब्राउज़र में समर्थित हैं [7]। यह वास्तव में पुन: उपयोग योग्य, रेस्पॉन्सिव कंपोनेंट बनाने का सही तरीका है जिन्हें यह जानने की जरूरत नहीं है कि उन्हें पेज पर कहाँ रखा जाएगा।

2026 में वास्तविक सिफारिश

लोग अभी भी “Flexbox बनाम Grid” के बारे में बहस करते हैं जैसे कि यह एक प्रतियोगिता है। दोनों का उपयोग करें। वे अलग-अलग समस्याएँ हल करते हैं।

उपयोग का मामला	टूल
पेज संरचना (हेडर, साइडबार, कंटेंट, फुटर)	CSS Grid
कंपोनेंट इंटर्नल (nav आइटम, बटन ग्रुप, फॉर्म पंक्तियाँ)	Flexbox
कार्ड जिन्हें क्रॉस-आइटम संरेखण चाहिए	CSS Grid + Subgrid
व्यूपोर्ट संदर्भ के बिना रेस्पॉन्सिव कंपोनेंट	Container Queries
वास्तविक टेबुलर डेटा	`<table>` — केवल वास्तविक डेटा के लिए
लेआउट के लिए Float	फिर कभी नहीं

मानसिक मॉडल सरल है:

Grid = आप दो आयामों में सोच रहे हैं। आप अपनी पंक्तियाँ AND कॉलम जानते हैं।
Flexbox = आप एक आयाम में सोच रहे हैं। चीज़ों की एक पंक्ति, या चीज़ों का एक कॉलम।

अगर आप कार्ड का ग्रिड बनाने के लिए display: flex; flex-wrap: wrap लिखते हुए खुद को पकड़ें — रुकें। यह Grid का काम है। Flexbox wrapping उन nav आइटम के लिए ठीक है जो रिफ्लो होनी चाहिए। यह संरचित मल्टी-कॉलम कार्ड के लिए अजीब है जहाँ पंक्तियों में संरेखण मायने रखता है।

और कृपया — लेआउट के लिए float: left समाप्त हो गया है। 2017 से ही समाप्त हो गया। अगर आप अभी भी यह कर रहे हैं, तो उस कोडबेस को एक रिफैक्टर की जरूरत है, Stack Overflow के जवाब की नहीं।

समाप्त