2 điểm bởi GN⁺ 2024-04-24 | 1 bình luận | Chia sẻ qua WhatsApp
  • Đang có một đề xuất nhằm bổ sung bố cục Masonry của CSS Grid (còn được gọi là bố cục xếp gạch hoặc thác nước) vào CSS Grid Level 3

    • Bố cục Masonry là một mẫu sắp xếp giúp lấp đầy nội dung dày đặc như gạch hoặc tường đá, có thể bố trí các nội dung có kích thước khác nhau mà không cần cắt hoặc lược bớt, đồng thời làm cho nội dung chảy theo từng cột
    • Đây là kiểu bố cục vốn khó triển khai chỉ bằng CSS mà không cần JavaScript
  • Đã tạo 4 bản demo để thử hiện thực cơ chế Masonry trong CSS

    • Tạo bố cục Masonry/thác nước cổ điển
    • Tận dụng các tính năng định nghĩa cột đa dạng của Grid
    • Tận dụng khả năng gộp cột của Grid
    • Sử dụng Subgrid và định vị tường minh
  • Khi kết hợp nhiều tính năng của Grid với Masonry, có thể hiện thực các bố cục sáng tạo và năng động hơn rất nhiều

    • Định nghĩa kích thước cột linh hoạt và đa dạng bằng đơn vị fr, max-content, min-content, hàm minmax()...
    • Gộp cột để nhấn mạnh một số phần tử nhất định hoặc tạo nên cấu trúc lưới phong phú hơn
    • Dùng Subgrid để đồng bộ track của lưới lồng nhau với lưới cha
    • Dùng định vị tường minh để chỉ định vị trí cho các phần tử cụ thể như header
  • Cũng có ý kiến cho rằng nên tách Masonry thành một kiểu display riêng

    • Có lo ngại rằng việc kết hợp CSS Grid và Masonry sẽ làm tăng độ phức tạp và ảnh hưởng xấu đến hiệu năng
    • Nếu tách Masonry khỏi Grid, mỗi bên có thể phát triển độc lập
    • Tuy vậy, cũng có quan điểm cho rằng Masonry chỉ nên được hiện thực như một bố cục cột có kích thước đồng nhất và bị giới hạn hơn
  • Tác giả cho rằng việc đưa Masonry vào CSS Grid mang lại nhiều lợi ích hơn

    • Đặc tả CSS Grid Level 3 đã được viết và đã có mặt trong 2 engine trình duyệt
    • Về sau có thể cung cấp cùng một tập tính năng mới cho cả Grid và Masonry (ví dụ: track styling)
    • Xét về mặt khái niệm, Masonry cũng là một dạng của Grid nên rất phù hợp
  • Tác giả muốn lắng nghe ý kiến từ các nhà thiết kế và lập trình viên web

    • Masonry có nên trở thành một phần của CSS Grid không?
    • Có muốn tận dụng toàn bộ tính năng của Grid như định nghĩa nhiều loại kích thước cột, gộp cột, định vị, Subgrid... hay tốt hơn là chỉ hỗ trợ các cột cùng kích thước?
    • Bạn sẽ dùng tính năng này như thế nào? Có thể tạo ra những kiểu bố cục nào?
    • Nếu có demo tự làm, hãy chia sẻ
    • Có kiểu bố cục nào khó triển khai với mô hình này không?
  • Tên gọi Masonry có thể không thật sự phù hợp. Có thể cân nhắc cú pháp như grid-template-rows: off với ý nghĩa loại bỏ hàng. Hãy lưu ý rằng tên gọi này có thể còn thay đổi trong tương lai

Ý kiến của GN⁺

  • Việc bổ sung tính năng Masonry vào CSS Grid là một thay đổi có ý nghĩa, có thể nâng cao đáng kể khả năng biểu đạt của bố cục web. Đặc biệt, việc dễ dàng hiện thực các grid dạng cột chỉ chảy theo chiều dọc là rất hấp dẫn
  • Ngược lại, khó đồng tình với quan điểm tách Masonry thành một kiểu display riêng và giới hạn tính năng của nó. Trái lại, khi kết hợp với các khả năng mạnh mẽ của Grid, phạm vi ứng dụng của bố cục Masonry có thể còn rộng hơn nhiều
  • Tuy nhiên, tên gọi Masonry không thật sự trực quan và có thể gây nhầm lẫn, nên cân nhắc một tên khác để chỉ loại grid chuyên cho cột. Cú pháp như grid-template-rows: none có vẻ tốt hơn vì truyền đạt rõ ý nghĩa "grid không có hàng"
  • Kỳ vọng đề xuất này sẽ giúp CSS Grid trở thành một công cụ mạnh mẽ hơn nữa. Việc thử nghiệm nhiều trường hợp bố cục khác nhau và tích cực đưa ra ý kiến có lẽ là rất quan trọng

1 bình luận

 
GN⁺ 2024-04-24
Ý kiến Hacker News

Tóm tắt:

  • CSSWG và các nhóm DevRel của các nhà cung cấp trình duyệt đã thảo luận từ năm 2020 về cách đưa bố cục Masonry vào CSS một cách chính thức
    • Nhóm WebKit quyết định công khai thảo luận này để lấy ý kiến từ các nhà thiết kế và lập trình viên
    • Đây sẽ là một tiền lệ quan trọng, đồng thời là cuộc tranh luận mang tính nền tảng về việc có nên xem mọi tùy chọn bố cục là một phần của CSS Grid hay tiếp tục bổ sung các thuộc tính CSS Display mới khi cần
  • Việc ví bố cục Masonry với cách xếp gạch thì khá thú vị, nhưng nếu thực sự xây gạch như vậy thì sẽ là một thảm họa về kỹ thuật kết cấu
  • Bản demo megamenu là một ví dụ sử dụng bố cục Masonry không phù hợp, làm rối loạn luồng đọc và đi ngược nghiêm trọng với kỳ vọng
    • Người dùng khiếm thị sẽ luôn phải đọc theo thứ tự “sai”
    • Lẽ ra nên triển khai bằng cột với break-inside: avoid
  • Bản demo báo chí cũng hơi đáng ngờ vì những lý do tương tự
  • Với hình ảnh hoặc phương tiện nằm trong các khối độc lập, bố cục Masonry hoạt động tốt hơn
  • Vì các bản demo này dựa trên bố cục grid, nên ngay cả ở những trình duyệt không hỗ trợ, chúng vẫn hiển thị dưới dạng hàng cố định hợp lý
  • Tôi thích cảm giác tổng thể của bố cục Masonry/Waterfall
    • Tuy nhiên, sẽ tốt hơn nếu có một kiểu bố cục giữ được luồng đọc trái-phải nhiều hơn thay vì cách sắp xếp Masonry mặc định
  • Suy nghĩ về cách thiết kế một hệ thống bố cục có thể thay thế CSS
    • Tò mò không biết trong các hệ thống đã được triển khai thực tế như Qt, Tk, SwiftUI... có điểm nào tốt hơn không
    • Làm thế nào để cung cấp cho lập trình viên một giao diện tốt hơn?
  • Giới thiệu một trường hợp tự triển khai hiệu ứng Masonry trên website ảnh cá nhân mà không cần JS
    • Dùng display:inline-block để coi ảnh như văn bản và cho chúng tự reflow sang dòng mới
    • Kết quả khiến họ hài lòng hơn so với thư viện Masonry
  • Đã có Flexbox và Grid layout rồi, nên có thể đặt câu hỏi liệu việc thêm nhiều tùy chọn “layout” hơn vào CSS có thực sự đúng hướng không
    • Một giải pháp tốt hơn có thể là xây dựng một hệ thống dựa trên ràng buộc mang tính tổng quát, dù phức tạp nhưng xử lý được mọi trường hợp bố cục
  • Thật vui khi lại thấy nhóm WebKit tiếp tục làm những việc rất tốt một cách công khai