Figma Auto Layout से CSS: यह Flexbox से कैसे मैप होता है (और कब Grid चुनें)

अगर आपने कभी किसी Figma फ़ाइल में किसी frame पर "Auto Layout" ऑन देखा है, तो असल में आप CSS Flexbox के बहुत करीब की चीज़ ही देख रहे थे — Figma के डिज़ाइनरों ने जानबूझकर यही मेंटल मॉडल उधार लिया है। direction, gap, padding और alignment लगभग एक-से-एक ट्रांसफर हो जाते हैं। जहाँ Figma-to-CSS मैपिंग ambiguous हो जाती है वह है sizing behavior: "hug", "fill" और "fixed" एक इरादे को बताते हैं, किसी एक CSS declaration को नहीं, और सही output इस बात पर निर्भर करता है कि उस element के आसपास का layout context क्या है। यह समझना कि मैपिंग कहाँ सीधी है और कहाँ नहीं, ही आपको डिज़ाइन फ़ाइल से मेंटेनेबल, responsive CSS तक बिना हर वैल्यू को आंख से अंदाज़ा लगाए ले जाता है।

Auto Layout असल में क्या कंट्रोल करता है

Auto Layout, Figma का वह तरीका है जिससे कोई frame एक असली layout container की तरह व्यवहार करता है, न कि सिर्फ़ absolute position की गई shapes के समूह की तरह। किसी frame पर इसे ऑन करते ही आपको कॉन्फ़िगर करने के लिए कुछ प्रॉपर्टीज़ मिलती हैं:

• Direction — क्या children vertically stack होंगे या horizontally।
• Spacing / gap — हर child element के बीच की fixed distance।
• Padding — frame के edge और उसके children के बीच की जगह, जो हर side के लिए अलग-अलग सेट की जा सकती है।
• Alignment — children primary axis और counter axis के साथ कैसे लाइन-अप होते हैं।
• Resizing behavior — क्या frame और उसके children अपने content के हिसाब से सिकुड़ते हैं, उपलब्ध space को fill करते हैं, या fixed size में रहते हैं।

इसमें कुछ भी मनमाना नहीं है। हर प्रॉपर्टी इसलिए मौजूद है क्योंकि यह उस जानकारी से जुड़ी होती है जो एक असली layout engine को जाननी ज़रूरी होती है — और यही वजह है कि यह ज़्यादातर मामलों में CSS Flexbox में इतनी साफ़-सुथरी तरह मैप हो जाती है।

Figma Auto Layout से Flexbox: प्रॉपर्टी मैपिंग टेबल

यह टेबल Figma-to-CSS ट्रांसलेशन का व्यावहारिक core है। ज़्यादातर rows सीधा swap हैं; कुछ context पर निर्भर करते हैं, जिसे Notes कॉलम में साफ़ बताया गया है।

एक ज़रूरी caveat: Figma का "Fill container" हमेशा किसी एक universal CSS declaration में ट्रांसलेट नहीं होता। इसे flex: 1 बनना चाहिए, width: 100%, या align-self: stretch — यह इस पर निर्भर करता है कि element flex container के अंदर है, block container के अंदर है, या grid के अंदर। एक ही Figma प्रॉपर्टी को उसके parent के हिसाब से अलग-अलग CSS चाहिए हो सकता है।

मेंटल मॉडल: Auto Layout Container → Flex Container

एक बार Figma की UI हटा दें, तो concepts सीधे मैच हो जाते हैं:

हर Auto Layout frame एक तरह से "wait कर रहा" flex container है। असली काम यह तय करना है कि हर frame के लिए, उसका sizing behavior आसपास के CSS में असल में क्या मतलब रखता है — जो अगले हिस्से में कवर किया गया है।

Hug Contents, Fill Container, और Fixed Sizing

Sizing behavior वह जगह है जहाँ हाथ से किया गया ज़्यादातर Figma-to-CSS काम गलत होता है, क्योंकि Figma एक इरादा express करता है जबकि CSS को एक specific declaration चाहिए होती है।

Hug contents

"hug contents" वाला element अपने content के इर्द-गिर्द अपनी size तय करता है — इसकी कोई fixed dimension नहीं होती और content बदलने पर यह बढ़ता या सिकुड़ता है। वेब पर, इसके सबसे करीब का equivalent अक्सर सिर्फ़ कोई explicit width या height सेट न करना होता है, क्योंकि block और flex items पहले से ही default रूप से अपने content के हिसाब से size लेते हैं। जहाँ explicit होना ज़रूरी हो, वहाँ width: fit-content या height: fit-content काफ़ी करीब पहुँच जाता है, लेकिन यह universally equivalent नहीं है — flex container के अंदर, बिना flex-grow वाला item पहले से ही बिना किसी अतिरिक्त CSS के "hug" जैसा व्यवहार करता है, इसलिए ऊपर से fit-content जोड़ना redundant हो सकता है, या कुछ browsers में default behavior से थोड़ा अलग भी।

/* Figma: Hug contents, horizontal Auto Layout */
.button {
  display: flex;
  width: fit-content; /* अक्सर ज़रूरी नहीं — flex items default रूप से पहले ही content के हिसाब से size लेते हैं */
}

Fill container

"fill container" वाला element उपलब्ध space इस्तेमाल करने के लिए फैलता है। सही CSS पूरी तरह parent पर निर्भर करता है:

• flex container के अंदर, main axis के साथ: flex: 1 (या flex-grow: 1)।
• flex container के अंदर, cross axis के साथ: align-self: stretch।
• block-level parent के अंदर: width: 100%।

/* Figma: Fill container, एक horizontal Auto Layout frame का child */
.sidebar-content {
  flex: 1;
}

"fill container → CSS" के लिए कोई एक rule नहीं है जो हर जगह काम करे। अगर parent का layout context ग़लत समझ लिया जाए, तो किसी ऐसे element पर flex: 1 लगाना जो flex item नहीं है, कुछ नहीं करता।

Fixed (फिक्स्ड साइज़)

Figma में fixed dimensions आमतौर पर CSS में explicit width और/या height से मैप होते हैं। लेकिन Figma से सीधे कॉपी किया गया एक pixel value अक्सर सही target नहीं होता — चेक करें कि डिज़ाइन का इरादा एक hard constraint (width: 240px) है, या किसी बाकी सब flexible element पर एक bound (min-width / max-width, min-height / max-height)। हर fixed value को hard width की तरह ट्रीट करना, ऐसे layouts की एक आम वजह है जो असली content या अलग-अलग viewports के हिसाब से adapt नहीं होते।

Auto Layout बनाम Constraints

Auto Layout और Constraints related लेकिन अलग-अलग समस्याएँ solve करते हैं, और इन्हें एक मान लेना ट्रांसलेशन errors की एक आम वजह है।

• Auto Layout यह कंट्रोल करता है कि किसी frame के children आपस में कैसे arrange होते हैं — direction, gap, padding, alignment, और sizing behavior। यह display: flex का सबसे करीबी equivalent है।
• Constraints यह कंट्रोल करते हैं कि कोई element उसके parent के resize होने पर कैसे व्यवहार करता है — left/right/top/bottom/center पर pinned, या scaled। Constraints उन elements के लिए सबसे ज़्यादा relevant हैं जो बिल्कुल किसी Auto Layout frame के अंदर नहीं हैं, या यह तय करने के लिए कि खुद Auto Layout frame किसी fixed-size parent के अंदर कैसे व्यवहार करता है।

व्यवहार में, किसी element के final CSS को अक्सर दोनों से जानकारी चाहिए होती है: Auto Layout आपको container और उसके children के लिए flex properties बताता है, जबकि constraints बताते हैं कि उस container को fixed माना जाए या उसे अपने parent के साथ resize होना चाहिए। इनमें से अकेला कोई भी पूरी responsive तस्वीर नहीं देता।

Auto Layout responsive CSS में कैसे मदद करता है

Auto Layout responsive behavior के लिए असली संकेत देता है, लेकिन यह अपने आप responsive CSS नहीं बन जाता। इस बारे में सटीक होना ज़रूरी है कि यह असल में क्या देता है:

• Auto Layout का sizing behavior (hug / fill / fixed) बताता है कि कौन-से elements को grow, shrink, या fixed रहना चाहिए — यही responsive layout की नींव है, जो सीधे flex, width: 100%, या एक fixed size में ट्रांसलेट होती है।
• Figma constraints इस बारे में जानकारी जोड़ते हैं कि container resize होने पर elements को कैसे व्यवहार करना चाहिए, जो उस सब पर लागू होता है जिसे Auto Layout गवर्न नहीं करता।
• इनमें से कोई भी breakpoints generate नहीं करता। अगर किसी डिज़ाइन का layout कुछ widths पर असल में shape बदलता है — columns का stack होना, navigation का collapse होना — तो अब भी CSS media queries चाहिए होती हैं, क्योंकि Figma frames आमतौर पर कुछ fixed viewport sizes represent करते हैं, उनके बीच के पूरे range को नहीं।
• डिज़ाइनर द्वारा असल में specify की गई sizes के बीच, fluid sizing (percentages, flex, minmax(), clamp()) अक्सर उस gap को भरने के लिए extra breakpoints जोड़ने से ज़्यादा ईमानदारी से इरादे वाला behavior reproduce करती है।

लक्ष्य यह है कि viewports के आर-पार layout का इंटेंडेड behavior reproduce किया जाए, न कि जिस Figma frame को आप उस वक्त देख रहे थे उसके pixel dimensions को कॉपी किया जाए।

कब CSS Grid बेहतर फ़िट है

Auto Layout एक single-axis model है: यह rows और columns में, यहां तक कि उनके nested combinations में भी, काफ़ी अच्छा काम करता है। लेकिन कुछ डिज़ाइन असल में two-dimensional होते हैं, और उन्हें nested Flexbox में जबरदस्ती फ़िट करने से ऐसा code बनता है जिसे मेंटेन करना खुद डिज़ाइन से भी मुश्किल हो जाता है। सही चुनाव layout पर निर्भर करता है — Flexbox one-dimensional arrangements में फ़िट बैठता है (navigation, button groups, cards की एक row, vertically या horizontally aligned content), जबकि Grid two-dimensional layouts में फ़िट बैठता है। इन स्थितियों में CSS Grid की तरफ जाएँ:

• ऐसा layout जहाँ items को rows और columns दोनों पर एक साथ align होना ज़रूरी है — जैसे card grids, dashboards, या image galleries।
• साफ़ तौर पर "यह element दो columns में फैलेगा" या "दो rows में फैलेगा" जैसा behavior, जिसे Grid grid-column / grid-row से नेटिवली संभालता है, जबकि Flexbox इसे सीधे express नहीं कर सकता।
• ऐसे डिज़ाइन जहाँ columns की संख्या fixed breakpoint list की बजाय उपलब्ध width के हिसाब से respond करनी चाहिए (repeat(auto-fit, minmax(...)))।
• एक ही grid के अंदर overlapping या layered regions, जो Grid के placement system से आसान होते हैं लेकिन Flexbox के साथ काफ़ी अटपटे हो जाते हैं।

एक आसान rule of thumb: अगर किसी Figma frame का Auto Layout किसी भी वक्त सिर्फ़ एक ही direction में nest होता है, तो Flexbox एक ईमानदार translation है। अगर आप खुद को row-and-column alignment नक़ल करने के लिए Auto Layout frames की पूरी grid बनाते हुए पाते हैं, तो अक्सर यह इस बात का संकेत होता है कि Figma का UI उसमें native two-dimensional Grid layout mode न होने की कमी पूरी कर रहा है — और तब असली CSS Grid generate करना ज़्यादा बेहतर रहता है।

Auto Layout से CSS में आम गलतियाँ

साफ़ मैपिंग होने के बावजूद, जो डेवलपर्स Auto Layout को हाथ से दोबारा बनाते हैं वे अक्सर कुछ खास चीज़ों में उलझते हैं:

• मिक्स्ड alignment फ्लैट हो जाता है। Figma में हर child ग्रुप के alignment को override कर सकता है; इसे सरसरी तौर पर देखकर सबके ऊपर एक ही align-items वैल्यू लगा देना आसान है, जिससे वे individual overrides खो जाते हैं जिनके लिए align-self चाहिए होता है।
• "hug" और "fill" के बीच confusion। content के हिसाब से सिकुड़ने वाला frame किसी एक viewport size पर fixed-width frame जैसा ही दिखता है, लेकिन content या screen size बदलते ही इसका व्यवहार पूरी तरह अलग हो जाता है।
• gap की जगह margin पर भरोसा करना। कुछ डेवलपर्स अब भी gap की जगह margin वाली ट्रिक्स इस्तेमाल करते हैं, जो पुरानी Flexbox सलाह से चली आ रही आदत है — जबकि अब gap को browsers में अच्छा support मिल चुका है, यह ज़रूरी नहीं रहा, और ऐसा करने से वही spacing bugs वापस आ जाते हैं जिन्हें ठीक करने के लिए gap बनाया गया था।
• nested Auto Layout frames बिना किसी योजना के nested flex containers बन जाते हैं। हर nested frame अपना खुद का flex context होता है, और अगर एक-से-एक literal translation किया जाए तो layout को असल में जितने चाहिए उससे ज़्यादा wrapper elements बन सकते हैं।
• padding गलत element पर लग जाना। frame का padding container की बजाय किसी child element पर लगा देना आसान है, जिससे sibling elements के बीच gap-based spacing गड़बड़ हो जाती है।
• यह मान लेना कि अकेला Auto Layout किसी layout को responsive बना देता है। जैसा ऊपर बताया गया, Auto Layout और constraints responsive behavior के बारे में जानकारी देते हैं — जब layout का shape असल में बदलना ज़रूरी हो, तो ये media queries की जगह नहीं ले सकते।
• two-dimensional grid नक़ल करने के लिए Flexbox को nest करना। अगर आप rows और columns दोनों को align करने के लिए Auto Layout frames को stack कर रहे हैं, तो आमतौर पर यह संकेत है कि CSS Grid ज़्यादा सही target है।

Figma-to-code वर्कफ़्लो में Auto Layout का इस्तेमाल

यह मैपिंग समझने में तो आसान है, लेकिन किसी असली design file के हर frame, हर gap value, और हर nested container पर इसे सही तरीके से लागू करना — साथ ही direction, sizing behavior, और frames के बीच hierarchy को interpret करना भी — थकाऊ काम है। और यह ठीक वैसा ही repetitive translation work है जिसे solve करने में मदद के लिए MarkupGen बनाया गया है। workflow चार steps में है: companion plugin की मदद से Figma से frame export करें, जो structure, styles और images सीधे आपके workspace में ले आता है; MarkupGen का AI उसी असली structure से HTML और CSS बनाता है, और Auto Layout के direction, gap, padding व alignment को बराबर के Flexbox structure में मैप कर देता है; फिर आप app के अंदर मौजूद editor में content, fonts और layout को visually refine करते हैं; और आख़िर में final code package export करते हैं। Responsive breakpoints, design की resizing constraints से generate होते हैं, और आप अपने stack के हिसाब से output format चुन सकते हैं — vanilla HTML/CSS, Tailwind CSS, या React components। जैसे किसी भी automated conversion में होता है, hug/fill/fixed elements के sizing behavior और उसके अनुमानित breakpoints को रिव्यू करें — ये एक अच्छी शुरुआत हैं, लेकिन डिज़ाइन के मुक़ाबले result चेक करने का विकल्प नहीं। अगर आप खाली फ़ाइल की बजाय किसी working example से शुरू करना चाहते हैं, तो अपनी design पर MarkupGen का Figma to HTML converter आज़माएँ, या पूरी end-to-end workflow जानने के लिए Figma-to-HTML conversion गाइड पढ़ें।

अक्सर पूछे जाने वाले सवाल

Figma Auto Layout CSS में कैसे ट्रांसलेट होता है? Direction, gap, padding और alignment सीधे flex-direction, gap, padding, और justify-content/align-items में मैप होते हैं। Sizing behavior — hug, fill, और fixed — भी CSS में मैप होता है, लेकिन exact declaration एक fixed one-to-one swap होने की बजाय आसपास के layout context पर निर्भर करता है।

क्या Figma Auto Layout, CSS Flexbox जैसा ही है? ये आपस में करीबी रूप से जुड़े हैं, पर identical नहीं हैं। Auto Layout को जानबूझकर Flexbox के concepts पर model किया गया था, इसलिए ज़्यादातर properties सीधे transfer होती हैं। मुख्य फ़र्क़ यह है कि Figma sizing को design intent (hug, fill, fixed) के तौर पर express करता है, जबकि CSS में आपको वह specific declaration चुननी होती है जो किसी दिए गए context में उस intent को produce करे।

CSS में "hug contents" का क्या मतलब है? इसका मतलब है कि element fixed या stretched size लेने की बजाय अपने content के इर्द-गिर्द अपनी size तय करता है। वेब पर यह अक्सर बिना explicit width वाले block और flex items का default behavior होता है, या ज़रूरत पड़ने पर इसे width: fit-content / height: fit-content से explicit बनाया जा सकता है।

CSS में "fill container" का क्या मतलब है? इसका मतलब है कि element अपने parent में उपलब्ध space इस्तेमाल करने के लिए फैलता है। context के हिसाब से, यह flex container के main axis पर flex: 1, cross axis पर align-self: stretch, या block-level parent के अंदर width: 100% हो सकता है — ऐसा कोई एक declaration नहीं है जो हमेशा लागू हो।

क्या Figma Auto Layout अपने आप responsive CSS बना देता है? नहीं। Auto Layout का sizing behavior और Figma के constraints इस बारे में उपयोगी संकेत देते हैं कि elements को कैसे adapt होना चाहिए, लेकिन जिन layouts का shape अलग-अलग widths पर बदलता है उनके breakpoints अब भी CSS media queries के रूप में लिखने पड़ते हैं।

किसी Figma डिज़ाइन के लिए CSS Grid या Flexbox, किसे इस्तेमाल करना चाहिए? यह इस बात पर निर्भर करता है कि layout कैसा है, न कि कौन "बेहतर" है। Flexbox one-dimensional arrangements में फ़िट बैठता है — rows, columns, navigation, button groups। Grid असल में two-dimensional layouts में फ़िट बैठता है, जैसे dashboards या card grids जहाँ items को rows और columns दोनों पर एक साथ align होना ज़रूरी है।