MarkupGenMarkupGen
คู่มือแหล่งข้อมูลบล็อกกรณีการใช้งานเปรียบเทียบ
เข้าสู่ระบบแปลงไฟล์ฟรี
  1. MarkupGen
  2. /บล็อก
  3. /Figma Auto Layout สู่ CSS: แม็ปไปเป็น Flexbox อย่างไร (และเมื่อไหร่ควรใช้ Grid)
กลับไปที่บล็อก

เผยแพร่เมื่อ 2026-08-05 · โดย ทีม MarkupGen

Figma Auto Layout สู่ CSS: แม็ปไปเป็น Flexbox อย่างไร (และเมื่อไหร่ควรใช้ Grid)

Figma Auto Layout สู่ CSS: แม็ปไปเป็น Flexbox อย่างไร (และเมื่อไหร่ควรใช้ Grid)

ถ้าคุณเคยเปิดไฟล์ Figma แล้วเห็นเฟรมไหนเปิด "Auto Layout" อยู่ นั่นแปลว่าคุณกำลังมองเห็นสิ่งที่ใกล้เคียงกับ CSS Flexbox มาก ๆ อยู่แล้ว เพราะทีมออกแบบของ Figma ตั้งใจหยิบยืมแนวคิดนี้มาโดยตรง direction, gap, padding และ alignment แทบจะย้ายมาแบบหนึ่งต่อหนึ่งได้เลย ส่วนที่ทำให้การแม็ป Figma-to-CSS คลุมเครือคือพฤติกรรมการกำหนดขนาด "hug", "fill" และ "fixed" อธิบายถึงเจตนา ไม่ใช่ CSS declaration เดียวตายตัว และผลลัพธ์ที่ถูกต้องขึ้นอยู่กับบริบทของ layout ที่ล้อมรอบ element นั้นอยู่ การเข้าใจว่าตรงไหนแม็ปตรงตัว ตรงไหนไม่ตรง คือสิ่งที่ทำให้คุณแปลงจากไฟล์ดีไซน์ไปเป็น CSS ที่ดูแลรักษาง่ายและ responsive ได้ โดยไม่ต้องมานั่งกะระยะทุกค่าด้วยสายตา

Auto Layout ควบคุมอะไรบ้าง

Auto Layout คือวิธีที่ Figma ทำให้เฟรมหนึ่งทำตัวเหมือน layout container จริง ๆ แทนที่จะเป็นแค่กลุ่มของรูปทรงที่วางตำแหน่งแบบ absolute เมื่อเปิดใช้งานกับเฟรมใดเฟรมหนึ่ง คุณจะได้คุณสมบัติมาปรับตั้งค่าดังนี้

  • Direction — องค์ประกอบลูกเรียงตัวในแนวตั้งหรือแนวนอน
  • Spacing / gap — ระยะห่างคงที่ระหว่างองค์ประกอบลูกแต่ละตัว
  • Padding — พื้นที่ระหว่างขอบเฟรมกับองค์ประกอบลูก ตั้งค่าแยกแต่ละด้านได้
  • Alignment — องค์ประกอบลูกเรียงตัวตามแนวแกนหลักและแกนขวางอย่างไร
  • พฤติกรรมการปรับขนาด — เฟรมและองค์ประกอบลูกจะหดตามเนื้อหา ขยายเต็มพื้นที่ที่มี หรือคงขนาดคงที่

ไม่มีคุณสมบัติไหนถูกกำหนดขึ้นมาแบบสุ่มสี่สุ่มห้า แต่ละอย่างมีอยู่เพราะสอดคล้องกับข้อมูลที่ layout engine จริง ๆ ต้องรู้ ซึ่งเป็นเหตุผลว่าทำไมมันถึงแม็ปเข้ากับ CSS Flexbox ได้อย่างเป็นระเบียบในกรณีส่วนใหญ่

Figma Auto Layout สู่ Flexbox: ตารางแม็ปคุณสมบัติ

ตารางนี้คือแก่นสำคัญเชิงปฏิบัติของการแปลง Figma เป็น CSS แถวส่วนใหญ่คือการสลับตรง ๆ ส่วนบางแถวขึ้นอยู่กับบริบท ซึ่งคอลัมน์ Notes จะระบุไว้ชัดเจน

คุณสมบัติ Auto Layout ของ Figma เทียบเท่ากับ CSS หมายเหตุ
แนวนอน flex-direction: row ค่าเริ่มต้นของ Flexbox องค์ประกอบลูกเรียงจากซ้ายไปขวา
แนวตั้ง flex-direction: column องค์ประกอบลูกเรียงจากบนลงล่าง
Gap gap เทียบเท่าตรง ๆ ไม่ต้องใช้เทคนิค margin แทน
Padding padding ใช้กับตัวเฟรมที่เปิด Auto Layout ไว้ ไม่ใช่กับองค์ประกอบลูก
การจัดเรียง (แกนหลัก) justify-content ตัวควบคุมการจัดเรียงตาม "แกนหลัก" ของ Figma
การจัดเรียง (แกนขวาง) align-items หรือ align-self สำหรับลูกตัวเดียว Figma อนุญาตให้องค์ประกอบลูกตัวเดียว override การจัดเรียงของกลุ่มได้ — นั่นคือสิ่งที่แม็ปกับ align-self ไม่ใช่ align-items อีกตัว
Hug contents มักไม่กำหนดขนาดชัดเจน หรือ width/height: fit-content ไม่ใช่กฎตายตัวสำหรับทุกกรณี — ขึ้นอยู่กับว่า element นั้นเป็น flex item, block element หรืออย่างอื่น
Fill container flex: 1, width: 100%, หรือ align-self: stretch ขึ้นอยู่กับแกน ไม่มี CSS declaration ตัวเดียวที่ขยายเต็มคอนเทนเนอร์ได้เสมอ ตัวที่ถูกต้องขึ้นอยู่กับโหมด layout ของ parent
ความกว้าง/ความสูงคงที่ ระบุ width / height ตรง ๆ บางครั้งพร้อมขอบเขต min-/max- ดูตรงไปตรงมา แต่ควรเช็กว่าดีไซน์ตั้งใจให้เป็นข้อจำกัดตายตัว หรือแค่ขนาดเริ่มต้นทั่วไป
โหมดระยะห่าง ("packed" กับ "space between") gap สำหรับ packed; justify-content: space-between สำหรับ space-between ใน Figma สองโหมดนี้มักแยกกันใช้ไม่ได้พร้อมกัน — space-between กระจายพื้นที่แทนการใช้ gap คงที่
Auto Layout ที่ซ้อนกัน องค์ประกอบที่ซ้อนกัน แต่ละตัวมี display: flex ของตัวเอง เฟรมที่ซ้อนกันแต่ละชั้นคือ flex formatting context ที่แยกจากกัน — แปลโครงสร้าง ไม่ใช่แค่ค่า

ข้อควรระวังสำคัญ: "Fill container" ใน Figma ไม่ได้แปลงเป็น CSS declaration สากลตัวเดียวเสมอไป ว่าควรเป็น flex: 1, width: 100% หรือ align-self: stretch ขึ้นอยู่กับว่า element นั้นอยู่ใน flex container, block container หรือ grid — คุณสมบัติเดียวกันของ Figma อาจต้องใช้ CSS ต่างกันตาม parent

โมเดลความคิด: Auto Layout Container → Flex Container

พอตัดส่วนติดต่อผู้ใช้ของ Figma ออกไป แนวคิดทั้งสองฝั่งก็เรียงตรงกันโดยตรง

Figma CSS
เฟรมที่เปิด Auto Layout คอนเทนเนอร์ที่ตั้ง display: flex
Direction flex-direction
Alignment align-items / justify-content
Gap gap
Padding padding
พฤติกรรมการกำหนดขนาด (hug / fill / fixed) คุณสมบัติ width / height / flex

เฟรม Auto Layout ทุกเฟรมคือ flex container ที่รอการปลดล็อกอยู่แล้ว งานจริง ๆ คือการตัดสินใจสำหรับแต่ละเฟรมว่าพฤติกรรมการกำหนดขนาดของมันหมายถึงอะไรใน CSS ที่ตามมา ซึ่งจะอธิบายต่อไป

Hug Contents, Fill Container และการกำหนดขนาดคงที่

พฤติกรรมการกำหนดขนาดคือจุดที่การแปลง Figma เป็น CSS ด้วยมือมักพลาดมากที่สุด เพราะ Figma สื่อถึงเจตนา ในขณะที่ CSS ต้องการ declaration ที่ชัดเจน

Hug contents

Element แบบ "hug contents" จะกำหนดขนาดตามเนื้อหาของตัวเอง — ไม่มีมิติที่ตายตัว และจะโตหรือหดตามเนื้อหาที่เปลี่ยนไป บนเว็บ สิ่งที่ใกล้เคียงที่สุดมักเป็นการไม่กำหนด width หรือ height ชัดเจนเลย เพราะ block element และ flex item จะกำหนดขนาดตามเนื้อหาเป็นค่าเริ่มต้นอยู่แล้ว ในจุดที่จำเป็นต้องระบุชัดเจน width: fit-content หรือ height: fit-content จะใกล้เคียงมาก แต่ก็ไม่ได้เทียบเท่ากันเสมอไป ภายใน flex container item ที่ไม่มี flex-grow ก็มีพฤติกรรมแบบ "hug" อยู่แล้วโดยไม่ต้องใช้ CSS เพิ่ม ดังนั้นการเพิ่ม fit-content เข้าไปอีกอาจจะซ้ำซ้อน หรือในบางเบราว์เซอร์อาจต่างจากพฤติกรรมเริ่มต้นเล็กน้อย

/* Figma: Hug contents, Auto Layout แนวนอน */
.button {
  display: flex;
  width: fit-content; /* มักไม่จำเป็น — flex item หดตามเนื้อหาเป็นค่าเริ่มต้นอยู่แล้ว */
}

Fill container

Element แบบ "fill container" จะขยายเพื่อใช้พื้นที่ที่มีอยู่ CSS ที่ถูกต้องขึ้นอยู่กับ parent ทั้งหมด

  • ภายใน flex container ตามแกนหลัก: flex: 1 (หรือ flex-grow: 1)
  • ภายใน flex container ตามแกนขวาง: align-self: stretch
  • ภายใน parent ที่เป็น block-level: width: 100%
/* Figma: Fill container, เป็นลูกของเฟรม Auto Layout แนวนอน */
.sidebar-content {
  flex: 1;
}

ไม่มีกฎ "fill container → CSS" เดียวที่ใช้ได้ทุกที่ ถ้าเข้าใจบริบท layout ของ parent ผิด การใส่ flex: 1 ให้กับ element ที่ไม่ใช่ flex item ก็จะไม่มีผลอะไร

Fixed (ขนาดคงที่)

มิติแบบคงที่ใน Figma มักแม็ปกับ width และ/หรือ height ที่ระบุชัดเจนใน CSS แต่ค่าพิกเซลที่คัดลอกมาจาก Figma ตรง ๆ มักไม่ใช่เป้าหมายที่ถูกต้องเสมอไป ควรเช็กว่าดีไซน์ตั้งใจให้เป็นข้อจำกัดตายตัว (width: 240px) หรือเป็นขอบเขตของ element ที่ยืดหยุ่นได้ (min-width / max-width, min-height / max-height) การปฏิบัติกับทุกค่าคงที่เหมือนเป็น width ตายตัว เป็นสาเหตุทั่วไปที่ทำให้เลย์เอาต์ปรับตัวเข้ากับเนื้อหาจริงหรือ viewport ที่ต่างกันไม่ได้

Auto Layout กับ Constraints

Auto Layout และ Constraints แก้ปัญหาที่เกี่ยวข้องกันแต่ต่างกัน และการสับสนสองสิ่งนี้เป็นสาเหตุที่พบบ่อยของการแปลงที่ผิดพลาด

  • Auto Layout ควบคุมว่า องค์ประกอบลูก ของเฟรมจัดเรียงกันอย่างไร — direction, gap, padding, alignment และพฤติกรรมการกำหนดขนาด นี่คือสิ่งที่ใกล้เคียงกับ display: flex มากที่สุด
  • Constraints ควบคุมว่า element จะมีพฤติกรรมอย่างไร เมื่อ parent ของมันถูกปรับขนาด — ยึดติดกับซ้าย/ขวา/บน/ล่าง/กึ่งกลาง หรือปรับสเกล Constraints สำคัญที่สุดสำหรับ element ที่ไม่ได้อยู่ในเฟรม Auto Layout เลย หรือสำหรับการที่ตัวเฟรม Auto Layout เองมีพฤติกรรมอย่างไรภายใน parent ที่มีขนาดคงที่

ในทางปฏิบัติ CSS สุดท้ายของ element มักต้องการข้อมูลจากทั้งสองอย่าง Auto Layout บอก flex properties ของคอนเทนเนอร์และองค์ประกอบลูก ในขณะที่ constraints บอกว่าคอนเทนเนอร์นั้นควรถูกมองว่าเป็นแบบคงที่ หรือควรปรับขนาดไปพร้อมกับ parent ของตัวเอง ไม่มีตัวไหนเพียงตัวเดียวที่ให้ภาพรวม responsive ได้ครบถ้วน

Auto Layout รองรับ CSS responsive อย่างไร

Auto Layout ให้สัญญาณที่ใช้งานได้จริงสำหรับพฤติกรรม responsive แต่มันไม่ได้กลายเป็น CSS responsive โดยอัตโนมัติด้วยตัวมันเอง ควรระบุให้ชัดว่ามันให้อะไรจริง ๆ บ้าง

  • พฤติกรรมการกำหนดขนาดของ Auto Layout (hug / fill / fixed) บอกว่า element ไหนควรโต หด หรือคงที่ — นี่คือรากฐานของเลย์เอาต์ responsive ซึ่งแปลตรงเป็น flex, width: 100%, หรือขนาดคงที่
  • Constraints ของ Figma เพิ่มข้อมูลเรื่อง element ควรมีพฤติกรรมอย่างไรเมื่อคอนเทนเนอร์ของมันถูกปรับขนาด ซึ่งสำคัญสำหรับทุกอย่างที่ไม่ได้ถูกควบคุมโดย Auto Layout
  • ทั้งสองอย่างไม่ได้สร้าง breakpoint ให้เอง ถ้าเลย์เอาต์ของดีไซน์เปลี่ยนรูปทรงจริง ๆ ที่ความกว้างบางค่า เช่น คอลัมน์เรียงซ้อนกัน หรือ navigation ยุบตัว ก็ยังต้องใช้ CSS media queries อยู่ดี เพราะเฟรมของ Figma มักแสดงถึงขนาด viewport คงที่ไม่กี่ขนาด ไม่ใช่ทุกช่วงระหว่างนั้น
  • ระหว่างขนาดที่นักออกแบบระบุไว้จริง ๆ การกำหนดขนาดแบบ fluid (เปอร์เซ็นต์, flex, minmax(), clamp()) มักจะจำลองพฤติกรรมที่ตั้งใจไว้ได้ตรงกว่าการเพิ่ม breakpoint เพื่อเติมช่องว่าง

เป้าหมายคือการจำลองพฤติกรรมที่ตั้งใจไว้ของเลย์เอาต์ในทุก viewport ไม่ใช่การคัดลอกมิติเป็นพิกเซลจากเฟรม Figma ที่คุณบังเอิญกำลังดูอยู่

เมื่อไหร่ที่ CSS Grid เหมาะกว่า

Auto Layout เป็นโมเดลแกนเดียว มันทำงานได้ดีมากกับแถวและคอลัมน์ รวมถึงการซ้อนกันหลายชั้น แต่ดีไซน์บางแบบเป็นสองมิติอย่างแท้จริง การพยายามยัดมันเข้าไปใน Flexbox ที่ซ้อนกันจึงทำให้ได้โค้ดที่ดูแลรักษายากกว่าตัวดีไซน์เองเสียอีก ตัวเลือกที่ถูกต้องขึ้นอยู่กับเลย์เอาต์ — Flexbox เหมาะกับการจัดเรียงแบบมิติเดียว (navigation, กลุ่มปุ่ม, การ์ดเรียงเป็นแถว, เนื้อหาที่จัดเรียงตามแนวตั้งหรือแนวนอน) ส่วน Grid เหมาะกับแบบสองมิติ ให้เปลี่ยนไปใช้ CSS Grid เมื่อคุณเจอสิ่งเหล่านี้

  • เลย์เอาต์ที่องค์ประกอบต้องจัดเรียงให้ตรงกัน ทั้ง แถวและคอลัมน์ในเวลาเดียวกัน เช่น การ์ดกริด แดชบอร์ด หรือแกลเลอรีรูปภาพ
  • พฤติกรรมที่ระบุชัดเจนแบบ "องค์ประกอบนี้กินพื้นที่สองคอลัมน์" หรือ "สองแถว" ซึ่ง Grid รองรับได้โดยตรงด้วย grid-column / grid-row แต่ Flexbox ไม่สามารถแสดงออกได้โดยตรง
  • ดีไซน์ที่จำนวนคอลัมน์ควรปรับตามความกว้างที่มีอยู่ (repeat(auto-fit, minmax(...))) แทนที่จะยึดตามรายการ breakpoint ที่ตายตัว
  • พื้นที่ที่ซ้อนทับหรือเป็นชั้น ๆ ภายในกริดเดียวกัน ซึ่งทำได้ตรงไปตรงมาด้วยระบบการจัดวางของ Grid แต่ค่อนข้างฝืนถ้าใช้ Flexbox

กฎง่าย ๆ ที่ใช้ได้คือ ถ้า Auto Layout ของเฟรม Figma ซ้อนกันในทิศทางเดียวเสมอในแต่ละครั้ง Flexbox ก็เป็นการแปลที่ตรงตามต้นฉบับ แต่ถ้าคุณพบว่าตัวเองกำลังสร้างกริดของเฟรม Auto Layout ขึ้นมาเพียงเพื่อจำลองการจัดเรียงแบบแถว-คอลัมน์ นั่นมักเป็นสัญญาณว่า UI ของ Figma กำลังชดเชยการที่มันไม่มีโหมดเลย์เอาต์ Grid สองมิติแบบเนทีฟ ซึ่งในกรณีนั้นควรสร้าง CSS Grid จริง ๆ ขึ้นมาแทน

จุดพลาดที่พบบ่อยเมื่อแปลง Auto Layout เป็น CSS

แม้ว่าการแม็ปจะชัดเจน แต่นักพัฒนาที่สร้าง Auto Layout ขึ้นใหม่ด้วยมือก็มักสะดุดกับรายละเอียดซ้ำ ๆ เดิม ๆ

  • Alignment แบบผสมถูกทำให้แบนราบ. Figma อนุญาตให้องค์ประกอบลูกแต่ละตัว override การจัดเรียงของกลุ่มได้ การมองผ่าน ๆ แล้วใส่ค่า align-items เดียวให้ทุกอย่างจึงทำให้เสีย override เฉพาะตัวที่ควรใช้ align-self ไป
  • ความกำกวมระหว่าง "hug" กับ "fill". เฟรมที่ตั้งให้หดตามเนื้อหาจะดูเหมือนเฟรมความกว้างคงที่ทุกประการเมื่อดูที่ viewport ขนาดใดขนาดหนึ่ง แต่พฤติกรรมจะต่างกันโดยสิ้นเชิงเมื่อเนื้อหาหรือขนาดหน้าจอเปลี่ยนไป
  • ข้าม gap ไปใช้ margin แทน. นักพัฒนาบางคนยังคงใช้เทคนิค margin แทน gap ซึ่งเป็นความเคยชินจากคำแนะนำ Flexbox ยุคเก่า ทั้งที่ตอนนี้ gap ได้รับการรองรับจากเบราว์เซอร์อย่างกว้างขวางแล้ว การทำแบบนั้นไม่จำเป็นอีกต่อไป และยังทำให้บั๊กเรื่องระยะห่างที่ gap ถูกสร้างมาเพื่อแก้กลับมาอีกครั้ง
  • เฟรม Auto Layout ที่ซ้อนกันกลายเป็น flex container ที่ซ้อนกันแบบไม่มีแผน. เฟรมที่ซ้อนกันแต่ละชั้นคือ flex context ของตัวเอง การแปลแบบตรงตัวหนึ่งต่อหนึ่งอาจสร้างองค์ประกอบ wrapper มากเกินกว่าที่เลย์เอาต์ต้องการจริง ๆ
  • Padding ถูกใส่ผิดองค์ประกอบ. ง่ายมากที่จะใส่ padding ของเฟรมลงในองค์ประกอบลูกแทนที่จะเป็นคอนเทนเนอร์ ซึ่งทำให้ระยะห่างที่อิงกับ gap ระหว่างองค์ประกอบพี่น้องผิดเพี้ยนไป
  • คิดว่า Auto Layout อย่างเดียวจะทำให้เลย์เอาต์ responsive ได้. ดังที่กล่าวไปข้างต้น Auto Layout และ constraints เป็นเพียงข้อมูลประกอบพฤติกรรม responsive ไม่ได้มาแทน media queries เมื่อรูปทรงของเลย์เอาต์จำเป็นต้องเปลี่ยนจริง ๆ
  • ซ้อน Flexbox เพื่อจำลองกริดสองมิติ. ถ้าคุณกำลังเรียงซ้อนเฟรม Auto Layout เพื่อจัดแนวทั้งแถวและคอลัมน์ นั่นมักเป็นสัญญาณว่า CSS Grid คือเป้าหมายที่เหมาะกว่า

การใช้ Auto Layout ใน Figma-to-code Workflow

การแม็ปนี้เป็นที่เข้าใจกันดีอยู่แล้ว แต่การทำให้ถูกต้องในทุกเฟรม ทุกค่า gap และทุกคอนเทนเนอร์ที่ซ้อนกันในไฟล์ดีไซน์จริง — พร้อมกับตีความ direction, พฤติกรรมการกำหนดขนาด และลำดับชั้นระหว่างเฟรมไปด้วย — นั้นเป็นงานที่น่าเบื่อ และนี่คืองานแปลที่ทำซ้ำ ๆ ประเภทที่ MarkupGen ถูกสร้างขึ้นมาเพื่อช่วยแก้ปัญหานี้โดยเฉพาะ ขั้นตอนการทำงานมีสี่ขั้นตอน คือ ส่งออกเฟรมจาก Figma ด้วยปลั๊กอินคู่กัน ซึ่งจะดึงโครงสร้าง สไตล์ และรูปภาพเข้ามาในเวิร์กสเปซของคุณโดยตรง จากนั้น AI ของ MarkupGen จะสร้าง HTML และ CSS จากโครงสร้างจริงนั้น โดยแม็ป direction, gap, padding และ alignment ของ Auto Layout ไปเป็นโครงสร้าง Flexbox ที่เทียบเท่ากัน จากนั้นคุณปรับแต่งเนื้อหา ฟอนต์ และเลย์เอาต์แบบเห็นภาพในตัวแก้ไขภายในแอป แล้วจึงส่งออกแพ็กเกจโค้ดสุดท้าย breakpoint สำหรับ responsive จะถูกสร้างขึ้นจากข้อจำกัดการปรับขนาดของดีไซน์ และคุณสามารถเลือกรูปแบบผลลัพธ์ได้ตามสแต็กที่ใช้งาน — HTML/CSS ธรรมดา, Tailwind CSS, หรือ React components เหมือนกับการแปลงอัตโนมัติทั่วไป ควรตรวจสอบพฤติกรรมการกำหนดขนาดของ element แบบ hug/fill/fixed และ breakpoint ที่ระบบอนุมานมาด้วย มันเป็นจุดเริ่มต้นที่ดี แต่ไม่ใช่สิ่งทดแทนการตรวจผลลัพธ์เทียบกับดีไซน์จริง หากคุณอยากเริ่มจากตัวอย่างที่ใช้งานได้จริงแทนที่จะเริ่มจากไฟล์เปล่า ลองใช้ตัวแปลง Figma to HTML ของ MarkupGen กับดีไซน์ของคุณเอง หรืออ่านคู่มือการแปลง Figma เป็น HTML แบบเต็ม เพื่อดูขั้นตอนการทำงานแบบครบวงจร

คำถามที่พบบ่อย

Figma Auto Layout แปลงเป็น CSS ได้อย่างไร? Direction, gap, padding และ alignment แม็ปโดยตรงกับ flex-direction, gap, padding และ justify-content/align-items พฤติกรรมการกำหนดขนาด — hug, fill และ fixed — ก็แม็ปกับ CSS เช่นกัน แต่ declaration ที่แน่นอนขึ้นอยู่กับบริบทของ layout ที่ล้อมรอบ ไม่ใช่การสลับแบบหนึ่งต่อหนึ่งที่ตายตัว

Figma Auto Layout เหมือนกับ CSS Flexbox หรือไม่? ทั้งสองเกี่ยวข้องกันอย่างใกล้ชิด แต่ไม่ใช่สิ่งเดียวกัน Auto Layout ถูกออกแบบขึ้นโดยอิงจากแนวคิดของ Flexbox โดยตั้งใจ คุณสมบัติส่วนใหญ่จึงย้ายมาได้ตรง ๆ ความแตกต่างหลักคือ Figma แสดงการกำหนดขนาดเป็นเจตนาของดีไซน์ (hug, fill, fixed) ในขณะที่ CSS ต้องการให้คุณเลือก declaration ที่เฉพาะเจาะจงซึ่งสร้างเจตนานั้นในบริบทหนึ่ง ๆ

"hug contents" ใน CSS หมายถึงอะไร? หมายถึง element กำหนดขนาดตามเนื้อหาของตัวเอง แทนที่จะมีขนาดคงที่หรือถูกยืดออก บนเว็บ มักเป็นพฤติกรรมเริ่มต้นของ block element และ flex item ที่ไม่มีการระบุความกว้างชัดเจน หรือสามารถระบุให้ชัดเจนได้ด้วย width: fit-content / height: fit-content เมื่อจำเป็น

"fill container" ใน CSS หมายถึงอะไร? หมายถึง element ขยายตัวเพื่อใช้พื้นที่ที่มีอยู่ใน parent ของมัน ขึ้นอยู่กับบริบท อาจเป็น flex: 1 บนแกนหลักของ flex container, align-self: stretch บนแกนขวาง หรือ width: 100% ภายใน parent ที่เป็น block-level — ไม่มี declaration เดียวที่ใช้ได้เสมอ

Figma Auto Layout สร้าง CSS responsive ให้อัตโนมัติหรือไม่? ไม่ พฤติกรรมการกำหนดขนาดของ Auto Layout และ constraints ของ Figma ให้สัญญาณที่มีประโยชน์ว่า element ควรปรับตัวอย่างไร แต่ breakpoint สำหรับเลย์เอาต์ที่เปลี่ยนรูปทรงที่ความกว้างต่าง ๆ ก็ยังต้องเขียนเป็น CSS media queries อยู่ดี

ควรใช้ CSS Grid หรือ Flexbox สำหรับดีไซน์จาก Figma? ขึ้นอยู่กับเลย์เอาต์ ไม่ใช่ว่าตัวไหน "ดีกว่า" Flexbox เหมาะกับการจัดเรียงแบบมิติเดียว — แถว คอลัมน์ navigation กลุ่มปุ่ม Grid เหมาะกับเลย์เอาต์ที่เป็นสองมิติอย่างแท้จริง เช่น แดชบอร์ด หรือการ์ดกริดที่องค์ประกอบต้องจัดเรียงให้ตรงกันทั้งแถวและคอลัมน์พร้อมกัน

ลองใช้กับ Figma to HTML

อ่านเพิ่มเติมที่เกี่ยวข้อง

Figma to HTML เทียบกับ React เทียบกับ Tailwind: ควรเลือกแบบไหน?บล็อก

Figma to HTML เทียบกับ React เทียบกับ Tailwind: ควรเลือกแบบไหน?

คู่มือช่วยตัดสินใจสำหรับสามตัวเลือกเอาต์พุตของ MarkupGen ที่ถูกถามมากที่สุด — ควรส่งออก Figma เป็น HTML/CSS เมื่อไร ควรส่งออกเป็น React เมื่อไร และ Tailwind เหมาะกับตรงไหนกันแน่

อ่านเพิ่มเติม
จาก Figma สู่โค้ด: MarkupGen รองรับทั้ง React, Vue และ CSS Frameworkบล็อก

จาก Figma สู่โค้ด: MarkupGen รองรับทั้ง React, Vue และ CSS Framework

MarkupGen แปลงดีไซน์ Figma เป็น React หรือ Vue 3 component ได้ (รวมถึง Svelte และ Angular) หรือจะเป็น HTML/CSS กับ Tailwind, Bootstrap และอื่นๆ ก็ได้

อ่านเพิ่มเติม
วิธีประเมิน HTML ที่สร้างด้วย AI ก่อนนำไปใช้งานจริงบล็อก

วิธีประเมิน HTML ที่สร้างด้วย AI ก่อนนำไปใช้งานจริง

เช็กลิสต์ประเมินเอาต์พุต AI Figma-to-code นอกเหนือจาก "หน้าตาถูกต้อง" — ความแม่นยำด้านภาพ semantics responsiveness และการเข้าถึงได้

อ่านเพิ่มเติม
เอาต์พุต Figma-to-HTML พร้อมสำหรับ SEO หรือไม่ สิ่งที่ต้องตรวจสอบบล็อก

เอาต์พุต Figma-to-HTML พร้อมสำหรับ SEO หรือไม่ สิ่งที่ต้องตรวจสอบ

HTML ที่แปลงออกมาอาจเหมือนดีไซน์เป๊ะ แต่ยังทำร้าย SEO ได้ เช็กลิสต์สิ่งที่ควรตรวจก่อนเผยแพร่เอาต์พุต Figma-to-code

อ่านเพิ่มเติม
จาก Figma สู่ HTML ที่เข้าถึงได้: คู่มือปฏิบัติจริงบล็อก

จาก Figma สู่ HTML ที่เข้าถึงได้: คู่มือปฏิบัติจริง

สิ่งที่การเข้าถึงได้ต้องการจริงๆ ในเวิร์กโฟลว์จาก Figma สู่ HTML — มาร์กอัปเชิงความหมาย หัวข้อ ARIA ฟอร์ม คอนทราสต์ และการนำทางด้วยคีย์บอร์ด

อ่านเพิ่มเติม
จาก Figma สู่ CSS: คู่มือแปลงงานฉบับใช้งานจริงบล็อก

จาก Figma สู่ CSS: คู่มือแปลงงานฉบับใช้งานจริง

ข้ามเฟรมเวิร์กไปเลย ดูว่าค่าใน Figma แปลงเป็น CSS ธรรมดาที่แก้ไขเองได้อย่างไร และเมื่อไหร่ควรเลือกใช้แทน Tailwind หรือ Bootstrap

อ่านเพิ่มเติม
เปรียบเทียบ

MarkupGen เทียบกับ TeleportHQ: เครื่องมือแปลงโค้ด เทียบกับ แพลตฟอร์ม Low-Code

TeleportHQ รวมการส่งออกโค้ดจาก Figma เข้ากับ CMS ฟอร์ม และโฮสติ้งในตัว ส่วน MarkupGen ยังคงโฟกัสที่ผลลัพธ์ HTML/CSS/React แบบสแตนด์อโลนที่สะอาด

อ่านเพิ่มเติม
MarkupGen สำหรับ Front-End Developerกรณีการใช้งาน

MarkupGen สำหรับ Front-End Developer

ข้ามขั้นตอนรื้อสร้างงานด้วยมือ แปลงเฟรม Figma เป็น HTML/CSS หรือ React code ที่พร้อมใช้ แล้วเอาเวลาไปโฟกัสที่ logic ไม่ใช่ layout

อ่านเพิ่มเติม

แปลงดีไซน์ Figma ชิ้นต่อไปของคุณให้เป็นโค้ดได้ในไม่กี่นาที

เริ่มต้นใช้งานฟรีและส่งออก HTML, CSS หรือ React ที่สะอาดจากไฟล์ Figma ใดก็ได้

แปลงไฟล์ฟรี
MarkupGenMarkupGen© 2025 MarkupGen. สงวนลิขสิทธิ์
บล็อกกรณีการใช้งานเปรียบเทียบแหล่งข้อมูล
เกี่ยวกับเราเอกสารประกอบความเป็นส่วนตัวข้อกำหนดติดต่อ