HTML to Frame: एक DOM, Figma Auto Layout कैसे बनता है

किसी web पेज को तस्वीर में बदलना आसान है। उसे ऐसे Figma frames में बदलना जो किसी designer के बनाए जैसे व्यवहार करें — यही मुश्किल हिस्सा है। जो frame सही दिखता है लेकिन headline edit करते ही बिखर जाता है, वह screenshot से कुछ ख़ास बेहतर नहीं है।

यह लेख step by step बताता है कि HTML to Frames एक DOM को nested Figma frames में कैसे बदलता है, उसका Auto Layout engine कैसे तय करता है कि क्या stack बनेगा, और वह अपने काम को रखने से पहले उसकी जांच क्यों करता है।

DOM से frame tree तक

Web पेज एक tree है: body में sections होते हैं, sections में containers, containers में cards, cards में headings और buttons। Figma file भी एक tree है: frames में frames, text और vectors होते हैं।

HTML to frame conversion का मूल विचार एक tree को दूसरे पर map करना है:

• हर पेज और screen एक top-level frame बनती है। एक पेज का Desktop, Tablet और Mobile import साथ-साथ तीन frames बनाता है।
• Boxes की तरह काम करने वाले elements nested frames बनते हैं। उनके backgrounds, borders, radii, shadows और clipping, frame properties बन जाते हैं।
• Text, text layers बनता है जिसमें mixed styles बरकरार रहते हैं, इसलिए bold link वाला वाक्य एक ही text layer रहता है।
• SVG एडिटेबल vectors बनता है, और images, image fills बनती हैं।
• Pseudo-elements (::before, ::after), shadow DOM content और z-index order भी आते हैं, ताकि stacking वैसी ही रहे जैसी browser ने बनाई।

लक्ष्य एक ऐसा layers panel है जिसे designer पढ़ सके, हर DOM node का ढेर नहीं। अगर जांच के लिए आपको ज़्यादा बारीक layer structure चाहिए, तो उसके लिए Detailed layers option (Pro) है।

Frame naming

Top-level frames के नाम ऐसे रखे जाते हैं कि आप उन्हें बड़ी file में ढूंढ सकें:

example.com/pricing — Desktop (1920)

नाम में domain और path (और अगर हो तो query) होता है, बिना protocol और बिना www के, उसके बाद screen और उसकी width, और यह 60 characters तक सीमित है। Source URL भी frame पर save रहता है, और इसी से एक click वाला Re-import संभव होता है।

Step 1: पहले इसे pixel-exact बनाएं

Engine Auto Layout का अंदाज़ा लगाकर शुरू नहीं करता। यह एक ऐसे version से शुरू करता है जो सही दिखने की गारंटी देता है:

1. पेज चुनी गई width पर एक असली browser में render होता है। Desktop के लिए वह Site width है — एक width जिसे plugin पेज के असली डिज़ाइन से मापता है (full-bleed के लिए 1920, boxed sites के लिए box की width, fluid sites के लिए 1440)।
2. हर element की geometry और computed styles मापी जाती हैं।
3. Frame tree absolute positions के साथ बनाया जाता है, ताकि हर layer ठीक वहीं बैठे जहां browser ने उसे रखा।

यह absolute version सुरक्षा जाल है। इसके बाद की हर चीज़ एक सुधार है जिसे ख़ुद को साबित करना होता है।

Step 2: अंदर से बाहर Auto Layout निकालें

इसके बाद, engine frames को सबसे अंदर से बाहर की ओर देखता है। हर frame के लिए, वह उसके children की मापी गई geometry देखकर पूछता है: क्या इन्हें एक Auto Layout stack के रूप में बताया जा सकता है?

यह निकालता है:

• Direction — क्या children vertical या horizontal stack में रखे हैं?
• Wrapping — क्या वे wrapping rows बनाते हैं, जैसे cards के CSS grid या flex-wrap में?
• Gap — क्या children के बीच की spacing इतनी एक जैसी है कि वह एक gap value हो सके?
• Padding — हर तरफ़ children frame के किनारों से कितनी दूर हैं?
• Alignment — क्या वे हर axis पर start, center या end से aligned हैं?

अंदर से बाहर काम करना मायने रखता है: जब किसी card का content एक साफ़ vertical stack बन जाता है, तो card ख़ुद अपने आसपास की cards की row में एक item माना जा सकता है।

सबसे अहम बात, inference इस पर आधारित है कि browser ने असल में क्या render किया, CSS parse करने पर नहीं। Row चाहे flexbox, grid, floats या inline-block से बनी हो, मापा गया नतीजा एक ही होता है, और engine उसी से काम करता है।

Step 3: Responsive अर्थ जोड़ें

सही gap और padding वाला stack एक शुरुआत है, लेकिन वह अभी responsive design की तरह व्यवहार नहीं करता। Engine इरादा भी निकालता है:

• Centred content → Center. अगर content अपने parent में centred है, तो वह Center aligned होता है, ताकि frame resize होने पर centred रहे।
• Max-width boxes centred रहते हैं. Full-width section के अंदर maximum width वाला content container अपनी width रखता है और बीच में रहता है।
• बराबर cards और flex-grow → Fill. जो cards एक row को बराबर बांटते हैं, या जो elements जगह भरने के लिए बढ़ते हैं, उन्हें Fill container set किया जाता है।
• Logo … menu … icons → gap item, Fill बनता है. एक आम header में, groups के बीच की जगह ही फैलती है। Engine उस gap item को Fill बनाता है, ताकि header चौड़ा होने पर logo बाईं ओर और icons दाईं ओर रहें।

यही अंतर है उस frame में जो एक width पर पेज से मेल खाता है, और उस frame में जिसे आप सच में resize कर सकते हैं।

Step 4: हर child को verify करें (2 px tolerance)

यह वह हिस्सा है जो डिज़ाइन को बरकरार रखता है। किसी frame पर Auto Layout plan लागू करने के बाद, engine मूल pixel-exact layout के सामने हर child की position जांचता है। हर एक को वहां से 2 px के भीतर होना चाहिए जहां browser ने उसे रखा था।

• अगर हर child टिकता है, तो plan रखा जाता है।
• अगर नहीं, तो आसान plan आज़माया जाता है — उदाहरण के लिए, ज़्यादा महत्वाकांक्षी alignment या Fill settings के बिना एक सादा stack।
• अगर कोई plan नहीं टिकता, तो frame अपनी absolute positions रखता है।

नियम सीधा है: डिज़ाइन कभी नहीं टूटता। किसी मुश्किल section पर आपको कम Auto Layout frames मिल सकते हैं, लेकिन ऐसा layout नहीं मिलेगा जो चुपचाप खिसक जाए।

यह कितनी बार सफल होता है? असली sites पर हमारे tests में, लगभग 86–97% frames पर Auto Layout निकाला गया — उदाहरण के लिए एक product site पर 93% और Linear व Stripe पर 88%। नतीजे इस पर निर्भर करते हैं कि पेज कैसे बना है, इसलिए इन्हें माप समझें, गारंटी नहीं।

Step 5: Absolute रहने वाले frames के लिए constraints

जो frames absolute positions रखते हैं, उन्हें पीछे नहीं छोड़ा जाता। Engine उन्हें समझदार constraints देता है:

• Stretch — उन elements के लिए जो अपने parent में फैले हैं, जैसे full-width background layer।
• Scale — उन elements के लिए जिन्हें अनुपात में resize होना चाहिए।
• Center — अपने parent में centred elements के लिए।
• Min — बाईं या ऊपर की ओर pinned।
• Max — दाईं या नीचे की ओर pinned।

इसलिए absolute frame भी अपने parent के resize होने पर ठीक-ठाक व्यवहार करता है।

Step 6: Diagnostics — कोई frame absolute क्यों रहा

Results screen import के frames, layers और Auto Layout share बताती है, साथ ही missing fonts और warnings भी। यह यह भी बताती है कि ख़ास frames absolute क्यों रहे। व्यवहार में, absolute रहने वाले sections अक्सर वे होते हैं जहां children overlap करते हैं, सामान्य flow से बाहर होते हैं, या इतनी अनियमित spacing पर होते हैं कि उन्हें एक stack के रूप में नहीं बताया जा सकता।

ये diagnostics दो तरह से उपयोगी हैं:

• Designers के लिए — आपको पता होता है कि अगर पूरी तरह responsive चाहिए तो किन sections को हाथ से convert करना है।
• Developers के लिए — ये अक्सर ऐसे layout code का संकेत होते हैं जो ज़रूरत से ज़्यादा जटिल है।

CSS flexbox और grid से Auto Layout: mapping table

क्योंकि engine मापी गई geometry से काम करता है, नीचे की mapping CSS properties का शाब्दिक अनुवाद नहीं, बल्कि आम नतीजा बताती है। गहराई से जानने के लिए CSS flexbox और grid से Figma Auto Layout देखें।

एक उदाहरण: तीन cards वाला pricing section

Steps को ठोस बनाने के लिए, एक आम section की कल्पना करें: ऊपर centred heading और subheading, फिर एक row में तीन pricing cards, हर एक में plan का नाम, price, features की list और एक button।

Engine आमतौर पर इसे ऐसे संभालेगा:

1. Pixel-exact build. हर element अपनी मापी गई position पर रखा जाता है। Section पहले से सही दिखता है।
2. पहले सबसे अंदर के frames. हर feature list एक जैसे gap वाला vertical stack बनती है। हर card एक vertical stack बनता है — नाम, price, list, button — जिसकी padding card के किनारों की दूरी से ली जाती है।
3. Cards की row. तीनों cards बराबर widths और बराबर spacing के साथ साथ-साथ हैं, इसलिए row एक gap वाला horizontal stack बनती है, और हर card Fill पर set होता है ताकि वे width बराबर बांटें।
4. Header block. Heading और subheading centred हैं, इसलिए वे Center aligned vertical stack बनते हैं।
5. Verification. हर frame के हर child को उसकी मूल position से जांचा जाता है। अगर, मान लें, "Most popular" badge बीच वाले card के ऊपरी किनारे पर overlap करता है, तो उस card का plan 2 px जांच में fail हो सकता है। Engine आसान plan आज़माता है, और अगर वह भी न टिके, तो card constraints के साथ absolute positions रखता है — और results screen बताती है कि वह कौन-सा frame था।

नतीजा एक ऐसा section है जिसे आप resize कर सकते हैं: frame चौड़ा करें और cards साथ में बढ़ते हैं; feature list edit करें और card उसके साथ बढ़ता है। Components & hover states (Pro) के साथ, तीनों cards एक component के instances के रूप में भी आ सकते हैं, क्योंकि उनका structure एक जैसा है।

व्यवहार में इसका क्या मतलब है

जब आप import किया पेज खोलते हैं, तो आप:

• Headline edit कर सकते हैं और section बढ़ता है, नीचे के content को नीचे धकेलते हुए।
• Card grid को कसने के लिए एक gap value बदल सकते हैं।
• Frame resize कर सकते हैं और देख सकते हैं कि Fill items फैलते हैं जबकि centred content अपनी जगह रहता है।
• किसी card को component instance से swap कर सकते हैं — और Components & hover states (Pro) के साथ, बार-बार आने वाले cards पहले से components हो सकते हैं।

यही frame tree को flatten की गई image से अलग करता है। HTML to canvas तुलना इस अंतर को विस्तार से बताती है।

बेहतर Auto Layout नतीजों के लिए tips

1. सही width पर import करें। Desktop को Site width इस्तेमाल करने दें, और हर breakpoint जांचने के लिए Responsive set से Tablet और Mobile जोड़ें।
2. Overlays छिपाएं। Hide cookie banners & popups on करें ताकि fixed dialogs sections पर overlap करके absolute positioning के लिए मजबूर न करें।
3. स्थिर states capture करें। Capture के समय animations freeze हो जाते हैं, लेकिन देर से load होने वाले content के लिए Extra wait (Pro) मदद करता है।
4. हाथ से कुछ भी convert करने से पहले diagnostics जांचें। वे ठीक-ठीक बताते हैं कि किन frames को देखना है।
5. जब आपको पुष्टि करनी हो कि layers live पेज से मेल खाते हैं, तो Reference screenshot इस्तेमाल करें (Pro)।

और जानें

• पूरा import flow: HTML को Figma में कैसे बदलें
• सभी conversion features: features
• हर option, समझाया हुआ: docs
• Plans और limits: pricing

Plugin पाएं और ऐसा पेज import करें जिसे आप अच्छी तरह जानते हैं। Engine को समझने का सबसे तेज़ तरीका है नतीजे को resize करके देखना कि क्या टिकता है।