Có một kiểu bàn giao thiết kế khá quen: bên Figma nhìn ngay ngắn, đến lúc developer dựng bằng CSS thì padding lệch, border làm khối phình ra, còn space-between bỗng cư xử khác bản thiết kế. Mình từng xem đây là chuyện hai công cụ nói hai ngôn ngữ, nên chỗ nào lệch thì sửa tay chỗ đó. Cách làm này chạy được, nhưng component càng lồng sâu thì phần “sửa sương sương” càng dễ tới công chuyện.
Ngày 24/07/2026, Figma công bố phiên bản Auto Layout mới để hành vi gần CSS Flexbox hơn. Mình chưa có quyền bật bản cập nhật này trên một file Figma production, vì vậy bài không giả vờ là review giao diện. Thay vào đó, mình đọc release note và tài liệu chính thức, rồi dựng một lab CSS nhỏ để kiểm tra năm thay đổi mà designer và developer cần nói với nhau trước khi nâng cấp file.
Mục lục [Hiển thị]
Vì sao Auto Layout cần tiến gần CSS?
Auto Layout vốn được tạo ra để mô phỏng cách giao diện web sắp xếp phần tử. Tuy nhiên, một số trường hợp biên chưa khớp với CSS: frame có thể nhỏ hơn tổng padding, stroke đôi khi tham gia phép tính layout theo cách khác border, hoặc khoảng cách tự động trở thành số âm khi các phần tử không còn chỗ.
Những khác biệt nhỏ này không chỉ làm developer khó chịu. Chúng tạo ra hai “sự thật”: một sự thật trên canvas và một sự thật trong trình duyệt. Khi component được dùng hàng chục lần, workaround như outline âm, node border riêng hoặc chỉnh padding thủ công sẽ trở thành nợ thiết kế.
Điểm mình thích ở cập nhật lần này là Figma không quảng cáo một hệ layout mới. Họ sửa những chỗ vốn dễ gây hiểu nhầm để thiết kế và CSS dùng chung một mô hình tinh thần hơn. Dev Mode cũng được Figma cho biết sẽ ánh xạ trực tiếp hơn sang thuộc tính Flexbox.
Năm thay đổi cần kiểm tra trước khi nâng cấp
Tài liệu Figma liệt kê năm nhóm thay đổi chính. Mình gom lại theo câu hỏi thực tế khi review component, thay vì đọc như một danh sách release note.
Padding luôn có đủ chỗ
Ở phiên bản cũ, một frame rộng 50 px vẫn có thể nhận padding trái và phải 30 px, tổng cộng 60 px. Kích thước khai báo và phần không gian cần dùng tự mâu thuẫn, nhưng frame vẫn có thể bị ép về 50 px. Phiên bản mới không cho frame nhỏ hơn lượng padding tối thiểu; nếu có inside stroke tham gia layout thì stroke cũng được cộng vào mức tối thiểu.
Chỗ này gần với CSS hơn, nhưng câu “giống border-box” dễ làm anh em hiểu quá nhanh. Mình dựng hai box có cùng width: 50px và padding-inline: 30px. Với box-sizing: border-box, trình duyệt vẫn phải bảo toàn padding, nên kích thước render tối thiểu không thể nhét nội dung vào một chiếc hộp vật lý nhỏ hơn tổng padding. Bài học không phải thuộc lòng con số; bài học là constraint vô lý sẽ bị clamp thay vì làm padding biến mất.
.frame {
box-sizing: border-box;
width: 50px;
padding-inline: 30px;
}
Sau khi cập nhật, hãy tìm các badge, icon button hoặc card từng dựa vào việc “nhồi” padding vào frame quá nhỏ. Nếu chúng lớn lên, đừng vội kéo width về số cũ. Kiểm tra lại token padding và kích thước chạm tối thiểu trước.
Inside stroke giống border, outside stroke giống outline
Figma mới chỉ tính inside stroke vào layout. Center stroke và outside stroke vẫn được vẽ, nhưng không thay đổi spacing hoặc phép tính fill. Cách nghĩ gần CSS nhất là inside stroke tương tự border, còn stroke nằm ngoài tương tự outline.
Điểm đáng chú ý thứ hai: thiết lập stroke của frame cha không còn ảnh hưởng cách tính stroke của frame con. Mỗi frame tự chịu trách nhiệm. Component lồng nhiều lớp vì thế có thể thay đổi sau nâng cấp, nhất là khi team từng dựa vào một setting ở cha để “cứu” stroke của con.
.component {
box-sizing: border-box;
border: 2px solid currentColor;
}
.focus-ring {
outline: 3px solid #3159b7;
outline-offset: 2px;
}
Đây cũng là dịp tốt để tách border trang trí khỏi focus ring. Nếu đang dùng một stroke để làm cả hai nhiệm vụ, bản thiết kế có thể đẹp nhưng khi sang code lại ảnh hưởng accessibility. Bài mình thử dialog CSS ít JavaScript hơn cũng gặp bài toán tương tự: phần nhìn và hành vi bàn phím phải được kiểm tra riêng, không thể nhìn canvas rồi đoán.
Fill container chia theo content area
Khi hai phần tử cùng đặt Fill container nhưng có padding hoặc inside stroke khác nhau, phiên bản cũ chia đều kích thước tổng. Kết quả là phần tử có border dày hơn nhận vùng nội dung nhỏ hơn. Phiên bản mới phân phối theo content area, nên phần tử có stroke dày có thể chiếm tổng chiều rộng lớn hơn để vùng bên trong vẫn bằng anh em của nó.
Mình mô phỏng bằng hai flex item cùng flex: 1, một item có border 2 px và item còn lại có border 8 px. Khi mọi phần tử dùng box-sizing: border-box, cần thống nhất câu hỏi team muốn chia đều cái gì: khung ngoài hay vùng nội dung. Hai đáp án đều hợp lệ về thiết kế, nhưng không thể vừa giữ tổng width bằng nhau vừa giữ content area bằng nhau nếu border khác nhau.
Nếu mục tiêu là các cột luôn chia đúng tỷ lệ bất kể stroke, tài liệu Figma đề xuất dùng Grid Auto Layout và track dạng fr. Ở phía web, CSS Grid cũng diễn đạt ý định này rõ hơn Flexbox:
.comparison {
display: grid;
grid-template-columns: repeat(2, minmax(0, 1fr));
gap: 16px;
}
Auto gap không còn tạo overlap ngoài ý muốn
Auto gap phân phối phần không gian còn trống giữa các phần tử. Trước đây, khi tổng chiều rộng con vượt frame, khoảng cách có thể trở thành số âm và làm các layer chồng lên nhau. Bản mới chặn auto gap ở mức 0; phần tử dồn về đầu frame thay vì tự overlap. Hành vi này gần với justify-content: space-between trong Flexbox.
Nếu thiết kế thực sự cần các thẻ chồng nhau, hãy đặt negative gap có chủ đích. Mình thấy quy tắc này dễ review hơn nhiều: overlap xuất hiện vì designer chọn một giá trị âm, không phải vì frame thiếu 12 px rồi công cụ tự sáng tác.
Một phần tử sẽ nằm ở đầu thay vì ở giữa
Với auto gap và chỉ có một child, phiên bản cũ đặt child ở giữa. Bản mới đặt nó về bên trái trong horizontal flow hoặc phía trên trong vertical flow. Đây là thay đổi nhỏ nhưng dễ làm empty state, thanh công cụ theo quyền người dùng hoặc danh sách được filter trông khác hẳn.
Trong lab CSS, space-between với một item không tự căn giữa; item ở đầu trục chính. Vì vậy cách mới nhất quán hơn. Nếu yêu cầu sản phẩm là căn giữa khi chỉ còn một phần tử, team nên biểu diễn điều đó bằng variant hoặc alignment rõ ràng, không dựa vào side effect của auto gap.
Mình dựng lab CSS để kiểm tra điều gì?
Mình tạo một trang HTML độc lập với ba nhóm test: padding lớn hơn width, hai item Fill có border khác nhau và một stack dùng space-between. Mục tiêu không phải chứng minh Figma render pixel giống Chrome, vì mình chưa chạy chính canvas mới. Mục tiêu là xác nhận mô hình CSS mà tài liệu đang hướng tới có nhất quán hay không.
Kết quả trên trình duyệt cho thấy ba nguyên tắc đều hợp lý: padding không thể bị xóa chỉ để giữ width phi thực tế; border và outline ảnh hưởng box model khác nhau; space-between không tạo negative gap. Phần cần thận trọng nhất là Fill container, vì cụm “chia đều” có thể nói về outer size hoặc content area. Designer nên ghi rõ ý định thay vì chỉ gửi một con số width.
| Trường hợp | Hành vi mới | Việc cần review |
|---|---|---|
| Padding lớn hơn width | Frame tăng tới kích thước tối thiểu | Badge, icon button, token padding |
| Inside stroke | Tham gia phép tính layout | Component có border dày |
| Center/outside stroke | Chỉ vẽ, không chiếm chỗ | Outline và focus ring |
| Nhiều Fill container | Ưu tiên content area bằng nhau | Card có stroke khác nhau |
| Auto gap thiếu chỗ | Gap dừng ở 0 | Chip, avatar, toolbar hẹp |
| Auto gap có một child | Child nằm ở đầu | Empty state và phân quyền |
Không nên nâng cấp cả design system trong một cú bấm
Figma cho phép frame cũ tiếp tục dùng legacy layout và có thể chuyển qua lại đến tháng 01/2027. Frame mới sẽ dùng hành vi mới mặc định. Khoảng chuyển tiếp này khá rộng, nhưng cũng tạo nguy cơ một file có hai phiên bản layout cùng tồn tại mà người review không để ý.
Mình sẽ không chọn “Update layout version for page” ngay trên thư viện chính. Cách ít đau đầu hơn là tạo branch hoặc bản sao, nâng cấp theo nhóm component, xem danh sách thay đổi trực quan rồi mới publish. Bắt đầu từ primitive như stack, button và card; sau đó mới đi lên template lớn.
- Chụp baseline ở các breakpoint quan trọng trước khi đổi.
- Tìm frame có padding lớn, stroke lồng nhau, Fill container và auto gap.
- Nâng cấp một nhóm component, không nâng cả page cùng lúc.
- So sánh instance ở trạng thái dài/ngắn, có lỗi, bị ẩn theo quyền và bản dịch dài.
- Đối chiếu Dev Mode với CSS thực tế, đặc biệt
box-sizing, border và alignment. - Chỉ republish library sau khi designer lẫn developer cùng duyệt.
Nếu dự án có nhiều nội dung tiếng Việt, bước kiểm tra chuỗi dài rất đáng làm. Font và box model thường dính nhau: chữ đổi dòng làm card cao hơn, rồi Auto Layout bị đổ oan. Kinh nghiệm xử lý font Unicode trong bài tùy biến font cho Laravel DomPDF vẫn đúng ở đây: phải khóa đúng font, weight và dữ liệu mẫu trước khi kết luận layout sai.
Checklist bàn giao giữa designer và developer
Sau cập nhật này, câu “Figma đã giống CSS rồi” vẫn quá rộng. Hai bên nên chốt một checklist ngắn trong pull request thiết kế hoặc ticket:
- Frame đang dùng legacy hay phiên bản Auto Layout mới?
- Kích thước mong muốn là outer box hay content area?
- Stroke là border tham gia layout hay outline chỉ để trang trí/focus?
- Overlap là chủ đích với negative gap hay lỗi do thiếu chỗ?
- Trạng thái một child phải nằm đầu hay căn giữa?
- Component đã được thử với nội dung dài và breakpoint hẹp chưa?
Khi đưa thiết kế lên website, phần layout chỉ là một nửa câu chuyện. Title, ảnh, canonical và cấu trúc heading vẫn phải được kiểm tra như trong checklist SEO kỹ thuật cho Botble CMS. Một component khớp Figma từng pixel nhưng làm trang tràn ngang trên mobile thì vẫn là một bản bàn giao chưa xong.
Ai nên chuyển sớm và ai nên chờ?
Team đang làm sản phẩm web mới, có designer và developer review cùng nhau, nên dùng hành vi mới cho frame mới ngay từ bây giờ. Việc cùng nói bằng padding, border-box, gap và alignment sẽ giảm khá nhiều workaround ở bước handoff.
Ngược lại, design system lớn có nhiều component lồng nhau không nên nâng cấp hàng loạt chỉ vì sợ chậm xu hướng. Figma xác nhận frame hiện có không tự đổi, và vẫn cho quay lại legacy đến tháng 01/2027. Hãy dùng thời gian đó để audit có bằng chứng.
Nhận định của mình sau khi đối chiếu tài liệu và lab CSS: đây là thay đổi tốt vì nó xóa bớt những ngoại lệ khó giải thích, chứ không phải một tính năng hào nhoáng. Mình chưa thử thao tác nâng cấp trực tiếp trên file Figma thật, nên phần preview thay đổi và tác động tới instance phức tạp vẫn cần kiểm tra trong tài khoản của từng team. Nhưng về mô hình layout, hướng đi mới dễ nói chuyện với code hơn rõ ràng.
Nguồn tham khảo
- Figma Release Notes, mục ngày 24/07/2026; kiểm tra ngày 01/08/2026.
- Figma Help Center: Use auto layout with CSS Flexbox in mind; kiểm tra ngày 01/08/2026.
- MDN: Introduction to the CSS box model; kiểm tra ngày 01/08/2026.
- MDN: justify-content; kiểm tra ngày 01/08/2026.
