เผยแพร่เมื่อ 2026-08-20 · โดย ทีม MarkupGen
จาก Figma สู่ CSS: คู่มือแปลงงานฉบับใช้งานจริง
คำตอบสั้นๆ: การแปลง Figma เป็น CSS ธรรมดา หมายถึงการแปลง Auto Layout ให้เป็น Flexbox การไขค่าของแต่ละ fill/spacing/type ออกมาเป็นตัวเลขจริง แทนที่จะประมาณด้วยคลาส utility และคงผลลัพธ์ให้ปราศจากการพึ่งพาไลบรารีใดๆ นี่คือตัวเลือกที่ใช่เมื่อคุณต้องการควบคุมทุกกฎ CSS ได้อย่างเต็มที่ โดยไม่ต้องเรียนรู้ ติดตั้ง หรือ override เฟรมเวิร์กใดๆ ในภายหลัง
ทำไมควรเลือก CSS ธรรมดาแทนเฟรมเวิร์ก
ทุกฟอร์แมตเอาต์พุตที่ MarkupGen รองรับ — CSS ธรรมดา, Tailwind, Bootstrap, Bulma — เริ่มต้นจากแหล่งข้อมูลเดียวกัน คือโครงสร้างและค่าจริงของเฟรม Figma ส่วน CSS ธรรมดาคือฟอร์แมตที่ไม่มีอะไรมาคั่นกลางระหว่างไฟล์ของคุณกับเบราว์เซอร์เลย
- ไม่ต้องเรียนรู้กฎการตั้งชื่อคลาส สเกล utility ของ Tailwind และคลาส component ของ Bootstrap ทรงพลังก็จริง แต่ก็ยังเป็นระบบที่ต้องทำความเข้าใจให้ซึมซับ ส่วน CSS ธรรมดาแค่รู้จัก CSS ก็พอ
- ไม่มีน้ำหนักของเฟรมเวิร์ก แม้จะมีการ purge คลาสที่ไม่ได้ใช้ เฟรมเวิร์กก็ยังเพิ่มขั้นตอน build และ dependency ที่ต้องคอยอัปเดต ส่วนเอาต์พุต CSS ธรรมดาไม่มีทั้งสองอย่างนี้
- แก้ไขได้ตรงจุดทุกกฎ การเปลี่ยนค่า spacing หมายถึงการแก้ declaration เดียว ไม่ต้องไล่หาว่าคลาส utility ไหน map กับค่าพิกเซลที่คุณต้องการ
ข้อแลกเปลี่ยนคือสิ่งที่ Tailwind มีไว้แก้ปัญหานี้โดยเฉพาะ เมื่อไม่มีเฟรมเวิร์กบังคับสเกล ค่า spacing และสีก็อาจเบี่ยงเบนไม่สม่ำเสมอเมื่อโค้ดเบสโตขึ้น หากไม่มีใครมีวินัยในการใช้ตัวเลขซ้ำเดิม สำหรับแลนดิ้งเพจเดี่ยวหรือเว็บไซต์ขนาดเล็ก นี่แทบไม่ใช่ปัญหา แต่สำหรับโปรดักต์ขนาดใหญ่ที่มีผู้ร่วมงานหลายคน ควรอ่าน Vanilla CSS vs Bootstrap vs Tailwind ก่อนตัดสินใจ
สิ่งที่ต้องแปลงจริงๆ มีอะไรบ้าง
เฟรม Figma มีโครงสร้างมากกว่าที่เห็นแวบแรก และแต่ละส่วนก็ map เข้ากับส่วนที่เจาะจงของ CSS
| คุณสมบัติของ Figma | ผลลัพธ์ CSS |
|---|---|
| ทิศทางของ Auto Layout | display: flex; flex-direction: row/column |
| ระยะห่าง (gap) ของ Auto Layout | gap |
| Padding ของ Auto Layout | padding |
| สีของ Fill | background-color (หรือ color สำหรับข้อความ) |
| Corner radius | border-radius |
| Effects (shadow, blur) | box-shadow / filter |
| Text style (ขนาด, น้ำหนัก, line-height) | font-size, font-weight, line-height |
| ข้อจำกัดการปรับขนาด (Resizing constraints) | กฎ width/height แบบ responsive ไม่ใช่เลย์เอาต์ตายตัวค่าเดียว |
ไม่มีอะไรในนี้ที่แปลกใหม่ — มันคือการ map แบบเดียวกับที่นักพัฒนาทำด้วยมือเมื่อสร้างดีไซน์ขึ้นใหม่ทีละพิกเซล ความต่างอยู่ที่การทำจากโครงสร้างและค่าจริงของเฟรม แทนที่จะกะด้วยสายตาจากภาพหน้าจอ
MarkupGen สร้าง CSS ได้อย่างไร
เวิร์กโฟลว์เหมือนกันทั้งสี่ขั้นตอนไม่ว่าจะเลือกฟอร์แมตเอาต์พุตแบบไหน คือ ส่งออกเฟรมจาก Figma ด้วยปลั๊กอินของ MarkupGen ซึ่งจับโครงสร้าง สไตล์ และรูปภาพมาพร้อมกัน จากนั้น AI จะสร้างมาร์กอัปจากโครงสร้างจริงนั้น ไม่ใช่การประมาณจากภาพ ปรับแต่งเนื้อหา ฟอนต์ หรือเลย์เอาต์ในตัวแก้ไขภายในแอปหากมีจุดที่ต้องแก้ แล้วจึงส่งออกแพ็กเกจสุดท้าย
สำหรับ CSS ธรรมดาโดยเฉพาะ นั่นหมายความว่าสไตล์ชีตที่สร้างขึ้นจะใช้ค่าสีและ spacing จริงของเฟรม แทนที่จะปัดเข้าสเกลที่กำหนดไว้ล่วงหน้าของเฟรมเวิร์ก — fill ที่ตั้งเป็น #3B82F6 ก็จะออกมาเป็นค่านั้นตรงๆ ไม่ใช่สีน้ำเงินที่ใกล้เคียงที่สุดของ Tailwind Auto Layout จะ map เป็นโครงสร้าง Flexbox โดยอัตโนมัติ (ดูรายละเอียดแบบทีละคุณสมบัติได้ที่ Auto Layout to CSS) และพฤติกรรม responsive ก็ถูกสร้างจากข้อจำกัดการปรับขนาดของเฟรม แทนที่จะต้องมาเพิ่มเป็นขั้นตอนแยกด้วยมือ เอาต์พุต HTML เน้นใช้ element เชิงความหมายมากกว่า <div> ที่ซ้อนกัน ซึ่งสำคัญทั้งต่อการดูแลรักษาโค้ด การเข้าถึงได้ และ SEO
แปลงตัวแปรของ Figma ให้เป็น CSS custom property
ตัวแปร (variables) ของ Figma (สี, ตัวอักษร, spacing, radius, effects) คือสิ่งที่ใกล้เคียงที่สุดที่ไฟล์ดีไซน์มีต่อระบบดีไซน์ (design system) และมันสอดคล้องในเชิงแนวคิดกับ CSS custom property — บล็อก :root ของคู่ --name: value ที่ทุกกฎในสไตล์ชีตสามารถอ้างอิงได้ ตามที่กล่าวไว้ข้างต้น เอาต์พุต CSS ของ MarkupGen ในตอนนี้จะไขค่าแต่ละคุณสมบัติออกมาเป็นค่าตายตัวต่อ element แทนที่จะสร้างเลเยอร์ตัวแปร :root นั้นให้อัตโนมัติ ดังนั้นการสร้าง mapping จึงเป็นขั้นตอนที่ต้องทำด้วยมือ อย่างไรก็ตาม มันเป็นขั้นตอนที่ทำตามรูปแบบได้ เมื่อคุณรู้แพทเทิร์นแล้ว:
| ตัวแปรของ Figma | ค่าตัวอย่าง | CSS custom property |
|---|---|---|
color/primary |
#3B82F6 |
--color-primary: #3B82F6; |
color/text-muted |
#6B7280 |
--color-text-muted: #6B7280; |
spacing/md |
16px |
--spacing-md: 16px; |
radius/lg |
12px |
--radius-lg: 12px; |
shadow/card |
0 4px 12px rgba(0,0,0,.08) |
--shadow-card: 0 4px 12px rgba(0,0,0,.08); |
font/heading |
24px / 600 / 1.2 | --font-heading-size: 24px; --font-heading-weight: 600; --font-heading-line: 1.2; |
หลักการตั้งชื่อที่ควรยึดไว้: ให้สะท้อนโครงสร้างกลุ่ม/ชื่อของตัวแปร Figma เอง (color/primary → --color-primary) แทนที่จะคิดค้นระบบคู่ขนานขึ้นมาใหม่ เพื่อให้ทั้งสองฝั่งยังคงอ้างอิงไขว้กันได้ง่ายเมื่อดีไซน์มีการพัฒนาไป เมื่อตัวแปรกลายเป็น custom property แล้ว ให้เปลี่ยนค่าตายตัวที่สร้างขึ้นให้เป็นการอ้างอิง var(--color-primary) ใน CSS ที่ส่งออกมา
มีข้อจำกัดสองข้อที่ควรรู้ก่อนจะพึ่งพาวิธีนี้: ไม่ใช่ทุกตัวแปรของ Figma ที่จะ map เข้ากับ CSS property เดียวได้อย่างเรียบร้อย — ตัวแปรที่ใช้ทั้งกับสีของเส้นขอบและสีของข้อความในจุดต่างๆ ของดีไซน์ ไม่ได้แปลว่ามันควรถูกผูกไว้ด้วยกันในโค้ด ถ้าจุดประสงค์ของมันแตกต่างกันจริงๆ และตัวแปรแบบ responsive (ค่า spacing ที่เปลี่ยนไปตาม breakpoint) จำเป็นต้องถูกประกาศใหม่ภายใน media query ที่เกี่ยวข้องแต่ละอัน เนื่องจาก custom property :root เดียวไม่สามารถเก็บค่าได้มากกว่าหนึ่งค่าในเวลาเดียวกัน — เฟรมแยกตาม breakpoint ของ Figma ไม่ได้แปลงมาเป็นการ override แบบ responsive ที่อิงกับ cascade ของ CSS โดยอัตโนมัติ
ตรวจสอบ CSS ที่สร้างขึ้นก่อนใช้งานจริง
- ตรวจหาค่าที่เบี่ยงเบน เมื่อไม่มีสเกล utility คอยบังคับความสม่ำเสมอ ให้สแกนหาค่าที่ใกล้เคียงกันแต่ไม่เท่ากัน (เช่น
padding: 15pxกับpadding: 16pxในอีกจุดหนึ่ง) ซึ่งน่าจะควรเป็นตัวเลขเดียวกัน - ยืนยันพฤติกรรม responsive ที่เบรกพอยต์จริง ไม่ใช่แค่ขนาดตั้งต้นของเฟรม — ลองปรับขนาดเบราว์เซอร์แทนที่จะเชื่อภาพหน้าจอเดียว
- ดูชื่อคลาส/selector หากโปรเจกต์มีกฎการตั้งชื่อของตัวเอง (BEM, CSS Modules ฯลฯ) และปรับให้ตรงก่อน merge
- ใช้ตัวแก้ไขภายในแอป สำหรับการปรับเนื้อหาหรือเลย์เอาต์ แทนที่จะแก้ไฟล์ที่เอ็กซ์พอร์ตออกมาด้วยมือ แล้วเอ็กซ์พอร์ตใหม่เพื่อไม่ให้ข้อมูลไม่ตรงกัน
ทุกการเอ็กซ์พอร์ตยังได้รับคะแนนคุณภาพจาก AI โดยอัตโนมัติ เทียบพรีวิวที่ใช้งานจริงกับดีไซน์ต้นฉบับ ทำให้คุณได้สัญญาณเร็วๆ ว่าโค้ดพร้อมใช้งานจริงหรือยังก่อนตรวจสอบด้วยตนเอง
คำถามที่พบบ่อย
เอาต์พุต CSS ใช้ CSS custom properties (ตัวแปร) หรือไม่ เอาต์พุตเน้นกฎมาตรฐานที่แก้ไขตรงจุดได้ในแต่ละ element แทนที่จะเป็นเลเยอร์ธีมที่ขับเคลื่อนด้วยตัวแปร — หากโปรเจกต์ของคุณใช้ระบบ custom properties ให้วางแผนนำค่าที่สร้างขึ้นไปรวมเข้าไปเองในภายหลัง
เลย์เอาต์เป็นแบบ responsive โดยดีฟอลต์หรือไม่ ใช่ — เบรกพอยต์ถูกสร้างจากข้อจำกัดการปรับขนาดของ Auto Layout ในเฟรม ไม่ใช่เพิ่มเข้ามาทีหลัง ดูวิธีการทำงานข้ามเลย์เอาต์มือถือ/เดสก์ท็อปที่แยกกันได้ที่ Figma Responsive Design: Auto Layout และ Constraints กำหนดเลย์เอาต์ Mobile/Desktop อย่างไร
ต่างจากเอาต์พุต Tailwind อย่างไร ใช้ข้อมูลต้นทางเดียวกัน แต่ปลายทางต่างกัน เอาต์พุต Tailwind จะไขค่าไปหาคลาส utility ที่ใกล้เคียงที่สุด (พร้อม fallback เป็นค่าตามใจสำหรับค่าที่หลุดสเกล) ส่วนเอาต์พุต CSS ธรรมดาจะคงค่าจริงของดีไซน์ไว้เป็น declaration มาตรฐาน เลือกตามว่าโปรเจกต์ของคุณใช้เฟรมเวิร์ก utility เป็นมาตรฐานอยู่แล้วหรือไม่
ลองใช้กับดีไซน์ของคุณเอง
หากคุณกำลังตัดสินใจระหว่างเอาต์พุต CSS ธรรมดากับแบบที่พึ่งเฟรมเวิร์ก วิธีที่เร็วที่สุดในการดูว่าแบบไหนเหมาะกว่าคือลองดูทั้งสองแบบบนดีไซน์เดียวกัน ลองใช้ MarkupGen ฟรี หรืออ่าน คู่มือการแปลง Figma เป็น HTML แบบเต็ม อยากดูภาพรวมสั้นๆ ก่อนไหม ดูได้ที่หน้า Figma to CSS converter