WebKit ขอความคิดเห็นเพื่อทำให้เลย์เอาต์ ‘Masonry’ ใน CSS Grid Level 3 เป็นมาตรฐาน

 (webkit.org)
2 คะแนน โดย GN⁺ 2024-04-24 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • WebKit ขอความคิดเห็นจากนักออกแบบและนักพัฒนาในกระบวนการทำให้ เลย์เอาต์ masonry/waterfall ซึ่งเป็นเรื่องยากมานานใน CSS กลายเป็นมาตรฐานใน CSS Grid Level 3
  • โมเดลที่เสนอคือการใช้ grid-template-rows: masonry บน display: grid เพื่อ ปิดการสร้างแถว แล้วเติมคอนเทนต์ลงในช่องว่างเหมือนการก่ออิฐ
  • Apple มองว่าฟีเจอร์นี้ควรอยู่ใน Grid เพื่อให้ผสานกับความสามารถเดิมของ Grid เช่น fr, minmax(), max-content, spanning, การจัดวางแบบระบุชัดเจน และ subgrid
  • แนวทางแยกเป็น display: masonry สามารถแยกประเภทเลย์เอาต์ได้อย่างเรียบง่าย แต่จากการอภิปรายมีแนวโน้มว่าจะถูกจำกัดอยู่ที่ คอลัมน์กว้างเท่ากัน เป็นหลัก และใช้งานความสามารถในการปรับขนาดแทร็กของ Grid ได้ยาก
  • หลังการอัปเดตเดือนตุลาคม 2024 CSS Working Group สรุปว่าแทร็กความกว้างแปรผัน การจัดวางแบบระบุชัดเจน spanning และ subgrid มีคุณค่าพอที่จะรวมไว้ใน masonry และสามารถทำให้มีประสิทธิภาพได้ แต่การอภิปรายเรื่องไวยากรณ์ยังคงดำเนินต่อไป

สถานะปัจจุบันของ CSS Grid Level 3

  • หลังการอัปเดตเดือนตุลาคม 2024 มีการจัดทำ W3C Working Draft อย่างเป็นทางการของ CSS Grid Layout Module Level 3 และมีการบันทึกพฤติกรรมของเลย์เอาต์ masonry ไว้ในเอกสาร
  • สมาชิก CSS Working Group สรุปว่าฟีเจอร์ต่อไปนี้มีคุณค่าพอที่จะรวมไว้ในเลย์เอาต์ masonry และสามารถนำไปใช้งานได้อย่างมีประสิทธิภาพ
    • แทร็กความกว้างแปรผัน
    • การจัดวางแบบระบุชัดเจน
    • spanning
    • subgrid
  • อย่างไรก็ตาม การถกเถียงเรื่องไวยากรณ์ยังเปิดอยู่ และ WebKit ได้อภิปรายต่อในบทความแยก Help us choose the syntax for Masonry in CSS

ทำไมจึงต้องมีเลย์เอาต์ masonry

  • CSS Grid Level 1 เปิดตัวในปี 2017 ช่วยลดภาระด้านขนาดและการจัดวางของเลย์เอาต์ที่อิงกับ float และ Grid Level 2 ให้บริการ Subgrid
  • แต่แม้หลังจาก CSS Grid ออกมาแล้ว คำถามว่า “จะเขียนเลย์เอาต์ masonry ด้วย CSS อย่างไร” ก็ยังไม่มีคำตอบที่ชัดเจนมาตลอด 7 ปี
  • เลย์เอาต์ masonry คือแพตเทิร์นที่คอนเทนต์ถูกจัดวางให้ประกบกันเหมือนอิฐหรือกำแพงหิน และเรียกอีกชื่อว่า waterfall layout
  • สามารถจัดการคอนเทนต์ที่มีอัตราส่วนภาพแตกต่างกันได้ จึงลดความจำเป็นในการครอปหรือย่อเพื่อทำให้ทุกรายการเป็นสี่เหลี่ยมขนาดเดียวกัน
  • เนื่องจากคอนเทนต์กระจายทั่วทั้งหน้า จึงรักษาลำดับการอ่านระหว่างเลื่อนได้อย่างเป็นธรรมชาติ และเมื่อเพิ่มคอนเทนต์แบบ lazy-load ที่ด้านล่างก็ไม่จำเป็นต้องขยับคอนเทนต์เดิม

ประวัติข้อเสนอและการถกเถียงเรื่องมาตรฐาน

  • กลไกสำหรับสร้างเลย์เอาต์ masonry ใน CSS ถูก Mozilla เสนอครั้งแรกในเดือนมกราคม 2020 ในฐานะ ส่วนขยายของ CSS Grid และถูกนำไปทดลองใช้ใน Firefox Nightly หลัง feature flag
  • Apple เริ่มนำข้อเสนอ CSS Grid Level 3 ไปใช้ใน Safari Technology Preview ในปี 2022 และปัจจุบันเปิดใช้งานเป็นค่าเริ่มต้น
  • ภายใน CSS Working Group มีความเห็นต่างกันเกี่ยวกับทิศทางพื้นฐาน
    • บางฝ่ายมองว่า masonry ไม่ควรเป็นส่วนหนึ่งของ CSS Grid แต่ควรเป็นประเภท display แยกต่างหาก
    • บางฝ่ายไม่แน่ใจว่าเลย์เอาต์นี้จำเป็นต่อเว็บหรือไม่ และเว็บไซต์ชื่อดังจะใช้หรือไม่
  • WebKit มองว่าหากเบราว์เซอร์จะปล่อยฟีเจอร์นี้ได้ ต้องมี ฉันทามติของ CSS Working Group ก่อน

วิธีใช้พื้นฐาน: Grid ที่ปิดแถวและใช้เฉพาะคอลัมน์

  • เลย์เอาต์ masonry/waterfall แบบคลาสสิกเขียนได้โดยใช้ display: grid กับองค์ประกอบ main กำหนดคอลัมน์ แล้วกำหนดค่า masonry ในทิศทางแถว
main {
  display: grid;
  grid-template-columns: repeat(auto-fill, minmax(14rem, 1fr));
  gap: 1rem;
  grid-template-rows: masonry;
}
  • grid-template-columns: repeat(auto-fill, minmax(14rem, 1fr)) สร้างคอลัมน์แบบยืดหยุ่นซ้ำ ๆ โดยมีความกว้างขั้นต่ำ 14rem
  • gap: 1rem สร้างระยะห่าง 1rem ระหว่างคอลัมน์และรายการ
  • grid-template-rows: masonry สั่งให้เบราว์เซอร์ ไม่ต้องสร้างแถว แต่ให้เติมคอนเทนต์ตามแพตเทิร์น masonry/waterfall
  • ตัวอย่างนี้สร้างเลย์เอาต์ยืดหยุ่นที่รองรับขนาดหน้าจอหลากหลายด้วย CSS สี่บรรทัด โดยไม่ต้องใช้ media query หรือ container query
  • ปัจจุบันชื่อค่า masonry อาจเปลี่ยนแปลงก่อนที่เบราว์เซอร์จะปล่อยใช้งานจริง

เหตุผลที่ต้องการคงความสามารถในการกำหนดคอลัมน์ของ Grid

  • WebKit สร้างเดโมสี่แบบเพื่อแสดงเหตุผลว่าทำไม masonry ควรเป็นส่วนหนึ่งของ CSS Grid และสามารถทดลองได้โดยตรงที่ webkit.org/demos/grid3
  • เดโมสามารถดูได้ในเบราว์เซอร์ที่รองรับ Grid Level 3
  • CSS Grid มีตัวเลือกหลากหลายเมื่อกำหนดคอลัมน์
    • ขนาดคงที่ด้วยหน่วยต่าง ๆ เช่น px, em, rem, cqi, lh, ch, ic, cap, vw, svh
    • max-content, min-content
    • หน่วย fr
    • minmax()
    • ขนาด %
    • auto
  • ตัวอย่างเช่น สามารถทำให้คอลัมน์แรกและสุดท้ายมีความกว้างคงที่ 14ch และคอลัมน์ตรงกลางเป็นคอลัมน์ยืดหยุ่นที่มีขั้นต่ำ 28ch ได้
main {
  display: grid;
  grid-template-columns: 14ch repeat(auto-fill, minmax(28ch, 1fr)) 14ch;
  grid-template-rows: masonry;
  gap: 1rem;
}
  • การผสานหน่วย fr กับ minmax() ทำให้เกิด ความยืดหยุ่นสองขั้น ที่คอลัมน์ขยายและหดในจังหวะต่างกัน
  • max-content และ min-content ทำให้ขนาดคอลัมน์สอดคล้องกับขนาดคอนเทนต์ เปิดทางให้จัดวางในแบบที่ต่างจากการปรับคอนเทนต์ให้เข้ากับคอลัมน์
  • อาจใช้ Fibonacci sequence เช่น grid-template-columns: 1fr 1fr 2fr 3fr 5fr 8fr; เพื่อสร้างคอลัมน์ที่มีความกว้างต่างกันได้
  • ตัวอย่าง mega menu ใช้ grid-template-columns: repeat(auto-fill, minmax(max-content, 30ch)); เพื่อให้แต่ละคอลัมน์ใหญ่พอที่จะใส่ข้อความลิงก์โดยไม่ขึ้นบรรทัดใหม่
  • WebKit มองว่าการอภิปรายเรื่อง display: masonry แยกต่างหากมีแนวโน้มไปในทิศทางที่อนุญาตเฉพาะ คอลัมน์ขนาดเท่ากัน คล้าย multicolumn layout ในปัจจุบัน

Spanning, View Transitions และ columnar grid

  • CSS Grid สามารถทำให้รายการกินพื้นที่หลายคอลัมน์ได้ จึงสร้างองค์ประกอบภาพที่หลากหลายในเลย์เอาต์ masonry ได้
  • ในตัวอย่าง สามารถทำให้ภาพทุกภาพที่ 5 กินพื้นที่สองคอลัมน์ และภาพที่เหลือกินพื้นที่เพียงคอลัมน์เดียวได้
  • ยังสามารถกำหนดคลาส wider ให้ภาพที่มีอัตราส่วนภาพกว้างกว่าเพื่อให้กินพื้นที่หลายคอลัมน์ รวมถึงปรับให้มุมเป็นสี่เหลี่ยมหรือลดระยะห่างเป็น 0 ได้
  • เดโม Photos ผสานกับ View Transitions เพื่อเมื่อผู้ใช้คลิกหรือแตะรูปภาพ รูปนั้นจะขยายกินพื้นที่หลายคอลัมน์ และเบราว์เซอร์จะทำแอนิเมชันการเปลี่ยนผ่านให้อัตโนมัติ
    • เดโมนี้ต้องใช้ Safari Technology Preview 192 ขึ้นไป
  • WebKit มองว่าแก่นของ Grid Level 3 คือ กลไกการปิดแถว มากกว่าแพตเทิร์นเฉพาะที่เรียกว่า “masonry”
  • วิธีนี้สร้าง columnar grid ที่ประกอบด้วยคอลัมน์เท่านั้น ซึ่งแตกต่างจาก modular grid ที่มีทั้งแถวและคอลัมน์เรียงตรงกัน ซึ่ง CSS Grid Level 1 ทำได้ดี

ความแตกต่างระหว่าง modular grid และ columnar grid

  • modular grid คือ Grid ที่คอนเทนต์ถูกจัดให้สอดคล้องทั้งคอลัมน์และแถว และ CSS Grid Level 1 เหมาะกับการจัดวางแบบนี้
  • เลย์เอาต์ที่อิงกับ float ก็เคยผลักดันให้เว็บใช้ modular grid เพราะต้องปรับความสูงของคอนเทนต์ให้เท่ากันเพื่อให้ float เคลียร์ได้ถูกต้อง
  • ในเว็บไซต์จริง มักพบการทำให้อัตราส่วนภาพของรูปเหมือนกัน การปรับความยาวข้อความให้เท่ากัน หรือการใช้กฎ CMS หรือ CSS ในการครอปและใส่จุดไข่ปลาเพื่อบังคับคอนเทนต์ให้พอดีกับกล่องเดียวกัน
  • columnar grid ปล่อยให้คอนเทนต์รักษาขนาดที่ต้องการไว้ และให้เลย์เอาต์ทำงานให้เข้ากับคอนเทนต์
  • WebKit มองว่าคอนเทนต์ที่เน้นข้อความก็สามารถจัดวางให้มีชีวิตชีวาขึ้นได้ ผ่านตัวอย่างที่ให้บทความล่าสุดกินพื้นที่สี่คอลัมน์ บทความล่าสุดบางส่วนกินสองคอลัมน์ และคอนเทนต์เก่ากินหนึ่งคอลัมน์

การผสาน Subgrid กับการจัดวางแบบระบุชัดเจน

  • subgrid ของ CSS Grid Level 2 รองรับในเบราว์เซอร์ส่วนใหญ่แล้ว
  • ตัวอย่างหน้าพิพิธภัณฑ์ใช้ subgrid เพื่อวางปีและหมายเลขแค็ตตาล็อกไว้ด้านขวาของการ์ดแต่ละใบ และจัดบรรทัดให้ตรงกับข้อมูลเดียวกันของการ์ดใบอื่น แทนที่จะลิสต์ metadata ของการ์ดภาพไว้ในคอลัมน์ชิดซ้ายหนึ่งคอลัมน์
  • หาก masonry เข้ามาอยู่ใน CSS Grid Level 3 เครื่องมือนักพัฒนาเดิมก็จะใช้งานต่อได้
    • สามารถทดลอง grid-template-rows: masonry ด้วย Grid Inspector ของ Safari Technology Preview ได้
  • หากกลายเป็น display type แยกต่างหาก จะไม่ได้รับ ประโยชน์ของ subgrid
  • ยังสามารถใช้การจัดวางแบบระบุชัดเจนของ CSS Grid Level 1 ร่วมกันได้ โดยในตัวอย่างใช้ grid-column: -3 / -1 เพื่อวาง header ไว้มุมขวาบนของหน้าในสองคอลัมน์สุดท้าย
  • WebKit มองว่าสามารถผสานฟีเจอร์ของ Grid Level 1, 2 และ 3 ด้วยโค้ดเลย์เอาต์ไม่กี่บรรทัด เพื่อสร้างเลย์เอาต์ที่จำนวนคอลัมน์เปลี่ยนตามพื้นที่ที่มี โดยไม่ต้องใช้ media query หรือ container query

ประเด็นกับ display: masonry

  • WebKit และ Apple มองว่า Masonry เป็นฟีเจอร์ที่ขยาย CSS Grid ให้สร้างได้ทั้ง modular grid และ columnar grid
  • ในแนวทางนี้ สามารถใช้ฟีเจอร์ของ Grid เช่น การกำหนดคอลัมน์, track spanning, การจัดวางแบบระบุชัดเจน และ subgrid ร่วมกันได้
  • ฝ่ายที่ชอบ display type แยกต่างหากมองว่าสามารถแยกประเภทเลย์เอาต์ได้อย่างสะอาด
display: block;
display: inline;
display: flexbox;
display: grid;
display: masonry;
  • CSS Working Group ยังไม่ได้อภิปรายไวยากรณ์ของ Masonry display type แยกต่างหาก แต่ WebKit ยกตัวอย่างไวยากรณ์ที่คล้าย Multicolumn layout หรือไวยากรณ์คล้าย Grid ที่จำกัดกว่า
main {
  display: masonry;
  columns: 28ch;
}

main {
  display: masonry;
  masonry-columns: repeat(5, minmax(28ch, 1fr));
                   /* where only one repeating width is allowed */
}
  • layout type แยกต่างหากสามารถหลีกเลี่ยงงานที่จำเป็นในการทำให้ Grid และ Masonry ทำงานร่วมกันต่อไปได้
    • โมเดลเลย์เอาต์เรียบง่ายขึ้น
    • เบราว์เซอร์นำไปใช้งานง่ายขึ้น
    • ลดโอกาสเกิดกับดักด้านประสิทธิภาพ
    • ชุดฟีเจอร์ของ Grid และ Masonry อาจแตกต่างกันได้
  • ในทางกลับกัน WebKit มองว่าหาก Grid layout ทั้งสองประเภทเชื่อมโยงกัน CSS Working Group จะต้องนิยามฟีเจอร์ในอนาคตสำหรับทั้ง modular grid และ columnar grid
  • เช่น หาก CSS Grid Level 4 เพิ่มฟีเจอร์อย่างการจัดสไตล์ grid area และ grid line, สีพื้นหลังของแทร็ก หรือ rule line ของ gap ก็ควรทำให้ทำงานกับ Grid ทั้งสองประเภทได้ตั้งแต่แรก

ควรมอง “Grid” อย่างไร

  • ฝ่ายที่สนับสนุน display: masonry แยกต่างหากบางคนมองว่า CSS Grid โดยเนื้อแท้คือการจัดแนวสองมิติ ส่วน masonry จัดแนวเพียงทิศทางเดียว จึงไม่ใช่ Grid
  • WebKit มองว่าในประวัติศาสตร์ graphic design นั้น grid เป็นเครื่องมือที่ช่วยจัดแนวข้อความ รูปภาพ และคอนเทนต์ให้เป็นแพตเทิร์นสม่ำเสมอ เพื่อช่วยเรื่องความอ่านง่ายและการใช้งาน
  • ก่อนที่นักโมเดิร์นนิสต์ในยุโรปและสหรัฐฯ ศตวรรษที่ 20 จะเน้นการจัดแนวทั้งคอลัมน์และแถวว่าเป็น graphic design grid ที่ “ถูกต้อง” ก็มีการใช้ grid หลากหลายรูปแบบอยู่แล้ว
  • Mark Boulton มองว่า columnar grid แบบสมมาตรเป็นทางการและน่าเบื่อ และส่งเสริมการใช้ compound grid แบบไม่สมมาตรในเว็บดีไซน์
  • CSS Grid Level 1 ทำให้สร้าง grid แบบไม่สมมาตรและ compound grid ได้ง่าย แต่ปัจจุบันจะเป็นเช่นนั้นเฉพาะเมื่อ Grid นั้นเป็น modular grid เท่านั้น
  • WebKit มองว่าทั้ง modular grid และ columnar grid ต่างก็เป็น grid และ CSS Grid ก็ควรมีความสามารถในการสร้าง columnar grid ด้วย

คำขอความคิดเห็นจากนักพัฒนาและนักออกแบบ

  • WebKit ขอให้นักพัฒนาและนักออกแบบสร้างเดโมเอง เขียนความคิดเห็นในบล็อกหรือโซเชียลมีเดีย และฝากความเห็นไว้ใน issue ของ CSS Working Group
  • คำถามที่ต้องการรับฟีดแบ็กมีดังนี้
    • “masonry”/“waterfall” ควรเป็นส่วนหนึ่งของ CSS Grid หรือไม่
    • จำเป็นต้องมีฟีเจอร์ของ columnar grid เช่น subgrid, spanning, การจัดวางแบบระบุชัดเจน และ track sizing หลากหลายหรือไม่
    • แค่เลย์เอาต์ masonry แบบคลาสสิกที่มีคอลัมน์ขนาดเท่ากันเพียงพอหรือไม่
    • จะใช้ฟีเจอร์นี้จริงหรือไม่ และสามารถสร้างอะไรได้บ้าง
    • มีลิงก์เดโมที่ทำไว้หรือไม่
    • มีสิ่งใดที่ทำไม่ได้ด้วยโมเดลนี้หรือไม่
  • ทีม WebKit ทำงานกับ Masonry มานานหนึ่งปีครึ่ง และเปิดใช้เป็นค่าเริ่มต้นใน Safari Technology Preview 163 เมื่อเดือนกุมภาพันธ์ 2023
  • แม้อยากปล่อยฟีเจอร์นี้เร็ว ๆ นี้ แต่ต้องแก้รายละเอียดรวมถึงชื่อ และคำถามพื้นฐานต่าง ๆ ให้ได้ก่อน

การอภิปรายเรื่องชื่อ: masonry, waterfall, off

  • WebKit มองว่า masonry มีโอกาสสูงที่จะไม่ใช่ชื่อที่ดีที่สุดสำหรับค่าใหม่นี้
  • ชื่อใน CSS มักเป็นคำง่าย ๆ ที่อธิบายผลลัพธ์โดยตรง เช่น center, contain, clip, wrap, smooth
  • masonry เป็นอุปมาที่ต้องมีคำอธิบายประกอบ จึงอาจจำยากสำหรับนักพัฒนาที่ไม่ได้ใช้ภาษาอังกฤษ
  • ในบางภูมิภาค เลย์เอาต์นี้ถูกเรียกว่า waterfall มากกว่า ดังนั้น grid-template-rows: waterfall ก็อาจเป็นตัวเลือกได้
  • WebKit มองว่าฟีเจอร์นี้ใกล้เคียงกับกลไกว่า “สร้าง Grid แต่ไม่ต้องสร้างแถว” มากกว่าเลย์เอาต์แบบ Pinterest โดยตัวมันเอง
  • grid-template-rows: none; อาจเหมาะในเชิงความหมาย แต่ none เป็นค่าเริ่มต้นของ grid-template-* อยู่แล้ว โดยหมายถึง “ขอเฉพาะแถวโดยนัย ไม่ต้องมีแถวแบบระบุชัดเจน” จึงใช้ไม่ได้
  • มีการเสนอทางเลือกเป็น grid-template-rows: off;
main {
  display: grid;
  grid-template-columns: repeat(auto-fill, minmax(14rem, 1fr));
  grid-template-rows: off;
}
  • CSSWG กำลังอภิปรายชื่อใน issue นี้
  • ปัจจุบัน Safari Technology Preview และเดโมใช้ค่า masonry ตาม Editor’s Draft แต่ในอนาคตชื่ออาจเปลี่ยนได้

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2024-04-24
ความคิดเห็นจาก Hacker News

  • ประเด็นเบื้องหลังคือบรรดา ผู้ดูแลความสัมพันธ์กับนักพัฒนาใน CSSWG ได้ถกเถียงกันมาว่าควรรวมเลย์เอาต์ Masonry เข้าเป็นส่วนหนึ่งของ CSS อย่างเป็นทางการอย่างไร เป็นการถกเถียงที่ดำเนินมาตั้งแต่อย่างน้อยปี 2020 ตอนที่ Firefox เสนอแนวคิดนี้ครั้งแรก
    ข่าวรอบนี้อยู่ที่ฝั่ง WebKit ดึงการถกเถียงนี้ออกมาสู่สาธารณะ และขอให้ดีไซเนอร์กับนักพัฒนาออกมาลงมือทำในทำนองว่า “ไปโพสต์บนโซเชียลมีเดีย เขียนบล็อกโพสต์กัน”
    ภายนอกมันอาจดูเหมือนกระบวนการเชิงพิธีการ แต่ก็อาจกลายเป็นบรรทัดฐานสำคัญได้ ประเด็นหลักคือควรจัดการตัวเลือกด้านเลย์เอาต์ทั้งหมดให้เป็นส่วนหนึ่งของ CSS Grid หรือควรเพิ่ม CSS Display แบบใหม่ขึ้นมาเรื่อย ๆ ทุกครั้งที่จำเป็น
    แบบแรกจะทำให้สเปก CSS Grid ที่ซับซ้อนอยู่แล้วซับซ้อนยิ่งขึ้น ส่วนแบบหลังอาจทำให้สเปก CSS พองตัวด้วยพร็อพเพอร์ตีและซับพร็อพเพอร์ตีใหม่ ๆ ไม่ว่าทางไหนก็ไม่ได้ง่ายอย่างที่เห็น

    • สาเหตุที่การวาง Masonry ไว้บน Grid มีความตึงเครียด ก็เพราะทั้งสองอย่างทำงานต่างกันโดยพื้นฐาน
      Grid จะวางไอเท็มทั้งหมดลงบนกริดก่อน แล้วค่อยกำหนดขนาดกริดหลังจากระบุตำแหน่ง เช่น col:2,row:3 ส่วน Masonry ในอุดมคติอยากกำหนดขนาดแทร็กก่อน แล้วค่อยวางไอเท็มลงบนแทร็กเหล่านั้น
      การติดตั้งใช้งานครั้งแรกของ Firefox และสเปกในตอนนั้นโดยพื้นฐานระบุว่า ยกเว้นแถวแรกกับกฎซับซ้อนบางอย่างแล้ว จะไม่เอาไอเท็ม Masonry มาคิดตอนคำนวณขนาดแทร็ก ทำให้เกิดสถานการณ์ที่ไอเท็มล้นแทร็กได้ง่ายมาก
      สเปกปัจจุบันกำหนดให้ลองวางไอเท็มทั้งหมดลงในทุกแทร็กที่เป็นไปได้ ในกรณีเลวร้ายที่สุดและก็พบได้บ่อยพอสมควร จะได้ประสิทธิภาพแบบกำลังสองที่ O(N_tracks * N_items) ซึ่งแย่ และแทบไม่มีอัลกอริทึมเลย์เอาต์อื่นที่เป็นแบบนี้[1]
      ถ้ามีการซ้อนกันหลายชั้น ประสิทธิภาพจะยิ่งแย่ลงแบบกึ่งเอ็กซ์โปเนนเชียล และถึง CPU จะเร็วก็ยังไม่ดีอยู่ดี อาจบอกได้ว่ากรณีแบบนี้ไม่ได้เกิดบ่อย แต่ในโหมดเลย์เอาต์ของ CSS ผู้คนมักจะทดสอบขีดจำกัดเสมอ ดังนั้นค่าเริ่มต้นจึงควรต้องเร็ว
      ใน Grid ไอเท็มสามารถกำหนดขนาดของตัวเองต่างกันได้ตามแทร็กที่ถูกวาง จึงจำเป็นต้องลองวางในทุกตำแหน่งที่เป็นไปได้ ส่วน Masonry หากต้องการบรรเทาปัญหานี้ อาจต้องใช้อัลกอริทึมอีกแบบในการคำนวณขนาดแทร็ก แต่บทความบล็อกยังพูดถึงประเด็นนี้ไม่มากพอ อาจเคยมี Grid เวอร์ชันการคำนวณขนาดที่ไม่ขึ้นกับตำแหน่งของไอเท็มก็ได้ แต่ตอนนี้สายเกินไปแล้ว
      [1] https://randomascii.wordpress.com/2019/12/08/on2-again-now-i...
    • Grid แบบ “ไม่มีแถว” เข้ากันได้ค่อนข้างดีกับ สเปก CSS Grid ปัจจุบัน เพราะสามารถนำพร็อพเพอร์ตีกำหนดคอลัมน์ที่ทรงพลังและ subgrid กลับมาใช้ซ้ำได้ และตัวอย่างต่าง ๆ ก็แสดงให้เห็นอย่างน่าเชื่อว่าฟีเจอร์เหล่านี้แยกขาดจากกันได้ดีเพียงใด
      โดยทั่วไปแค่ใช้ grid-row-template: masonry อย่างเดียว ที่เหลือก็ยังทำงานได้ดีเหมือนเดิม ซึ่งเป็นข้อดี และไม่น่าจะทำให้การใช้ Grid ยากกว่าที่เป็นอยู่
      ข้อเสียส่วนใหญ่อยู่ที่ผู้เขียนเอนจินเบราว์เซอร์ เพราะเกณฑ์ของคำว่า “รองรับ CSS Grid ครบถ้วน” จะสูงขึ้น อีกทั้งยังมี กับดักด้านประสิทธิภาพ ที่บอกกันว่าสามารถหลีกเลี่ยงได้ ถ้าสเปกเรียบง่ายกว่านี้ การติดตั้งใช้งานที่ต้องรองรับฟีเจอร์ของ Grid ทั้งหมดอาจไม่ช้าลงกับเลย์เอาต์ Grid บางแบบเท่าเดิม
      หากมี display mode แยกต่างหาก ก็จะต้องเขียนสเปก grid-column ซ้ำสำหรับเลย์เอาต์ Masonry ซึ่งก็น่าเสียดาย
    • นี่ไม่ใช่ครั้งแรกที่เรื่องแบบนี้ถูกส่งต่อไปให้ชุมชนช่วยให้ฟีดแบ็ก ตอน nested CSS selectors ก็ใช้วิธีเดียวกัน และในแง่ของฟีดแบ็กก็ทำงานได้ค่อนข้างดี: https://webkit.org/blog/13607/help-choose-from-options-for-c...
    • ระหว่างที่สำรวจจุดประนีประนอม ก็อาจทำให้ต้องกลับมาทบทวนความชอบตั้งต้นของตัวเองใหม่
      แม้จะไม่เกี่ยวกับ CSS Masonry โดยตรง แต่ไม่นานมานี้ได้ทำต้นแบบรอบที่สองของอินเทอร์เฟซหนึ่งที่มีความตึงเครียดคล้ายกัน เป็นปัญหาว่าควรเพิ่มชนิดข้อมูลที่คล้ายกันแต่ต่างกันเข้าไปใน data model มากขึ้น หรือควรเพิ่มรายละเอียดปลีกย่อยภายในชนิดที่มีอยู่เพื่อรองรับการทำให้ละเอียดขึ้น
      ตอนเริ่มต้นนั้นชอบแบบหลังอย่างมาก แต่เมื่อได้ลองสำรวจตัวเลือกจริง ๆ กลับพบว่าการบริโภคอินเทอร์เฟซที่ “พองตัว” มากขึ้น แล้วค่อยอนุมานโค้ดแอปพลิเคชันจากผลลัพธ์ กลับเรียบง่ายกว่ามาก
      สำหรับ CSS Masonry ไม่มีจุดยืนที่หนักแน่นนัก แต่ก็เป็นไปได้ว่าจะมีความประหลาดใจแบบเดียวกันระหว่างความตึงเครียดที่คนรู้สึกโดยสัญชาตญาณ กับสิ่งที่สัมผัสได้จากการใช้งานจริง โดยเฉพาะใน CSS นั้น “ความพองตัว” หรือการเพิ่มความหมายตามกรณีใช้งาน อาจอธิบายให้ชอบธรรมได้ยาก แต่ผู้ใช้ก็อาจรู้สึกว่า API ที่หนาแน่น อย่าง Grid ใช้งานยากกว่าเช่นกัน
    • การทำเรื่องนี้อย่างเปิดเผยต่อสาธารณะถือว่าดี ผมผลักดันเรื่องนี้กับทุกคนที่เกี่ยวข้องมาตั้งแต่ปีที่แล้ว ฝั่ง Chrome ตามหลังมากที่สุดและยังไม่รองรับ ตอนนี้ Firefox มีการรองรับหลัง flag แล้ว
      ผมทดสอบใน Firefox และ Safari มาตั้งแต่ปีที่แล้ว และไม่ได้มีปัญหากับตัว implementation เอง มีคนบ่นเรื่องตำแหน่งกับชื่อของพร็อพเพอร์ตีอยู่บ้าง แต่ก็ควรยอมรับว่าอาจไม่มีวิธีแก้ที่สมบูรณ์แบบ และควรลงมือทำแบบที่ใช้งานได้จริง
      ผมปฏิเสธที่จะใช้ JavaScript สำหรับ implementation ทางเลือก ดังนั้นวิธีทดแทนจึงมี CSS หน้าตาไม่น่าดูจำนวนมากที่จัดลำดับได้ไม่ถูกต้องนัก แต่ก็ไม่ใช่ปัญหาใหญ่สำหรับโปรเจ็กต์ที่กำลังทำอยู่ ตอนนี้คนส่วนใหญ่คงแทนที่ด้วย JavaScript แต่ถ้า คำตอบของปัญหาเลย์เอาต์คือ JavaScript ก็ถือว่าเริ่มต้นมาก็เสียเปรียบแล้ว

  • เดโมเมกะเมนู <https://webkit.org/demos/grid3/megamenu/> ไม่ถูกใจเอาเสียเลย และการใช้ Masonry ตรงนั้นก็ดูไม่เหมาะสมอย่างสิ้นเชิง มันทำให้ทิศทางการไหลของเนื้อหาปั่นป่วนจนผิดจากที่คาดหวังอย่างมาก
    ลำดับการอ่านที่คาดไว้: https://temp.chrismorgan.info/2024-04-23-masonry-megamenu-2....
    ลำดับที่เดโมจริงให้มา: https://temp.chrismorgan.info/2024-04-23-masonry-megamenu-1..... สิ่งนี้ส่งผลต่อทั้งลำดับการอ่านที่ถูกต้องและ tab index ผู้ใช้ที่มองเห็นจะอ่านในลำดับที่ “ผิด” แทบตลอดเวลา
    สุดท้ายมันแสดงให้เห็นว่าโครงสร้างนั้นไม่มีระเบียบ เป็นเพียงถุงรวมลิงก์แบบไร้รูปแบบเท่านั้น แต่พอลองไล่ตามหมายเลขก็จะเห็นว่าจริง ๆ แล้วเคยมีลำดับที่ค่อนข้างสมเหตุสมผลอยู่ และถูกทำพังไปหมดเพราะการทำให้เป็น Masonry อย่างไม่เหมาะสม
    ในภาพหน้าจอได้เปิด “แสดงหมายเลขรายการ” ไว้ ปกติแล้วมันจะดูเหมือนคอลัมน์ธรรมดาที่ไม่มีพื้นหลัง
    การทำงานควรใช้คอลัมน์และเพิ่ม break-inside: avoid ให้แต่ละเซกชัน แต่เดโมนี้พลาดจุดนั้นไป
    เดโมหนังสือพิมพ์ก็น่าสงสัยเล็กน้อยด้วยเหตุผลคล้ายกัน แต่ปัญหาเล็กกว่ามาก
    ถ้าเป็นบล็อกที่เป็นอิสระต่อกันมากกว่า เช่น สื่อประเภทภาพ ซึ่งลำดับการอ่านไม่ได้ฝังแน่นขนาดนั้น Masonry layout จะเหมาะกว่า ถึงอย่างนั้นก็ยังมีจุดกำกวมเล็กน้อยเรื่อง tab index อยู่บ้าง แต่ก็ไม่ถึงกับผิดอย่างชัดเจนอีกต่อไป

    • ถ้าหมายความว่า accessibility tree และลำดับแท็บข้ามลำดับเนื้อหาจริง แล้วไล่ทีละคอลัมน์ แบบนั้นผมมองว่าเป็น บั๊ก
      ใน Masonry layout ความคาดหวังของผู้ใช้ที่มองเห็นไม่ใช่ความต่อเนื่องระหว่างคอลัมน์ แต่เป็นการไล่ตามแถวที่เห็นด้วยสายตา ลำดับที่ถูกนำเสนอว่า “คาดไม่ถึง” ก็เป็นไปตามนั้น
      ปัญหาดูเหมือนจะอยู่ที่ลำดับแท็บพยายามเลียนแบบสิ่งที่มองเห็นโดยไม่สนลำดับเนื้อหาต้นฉบับ และแทบจะแน่ใจว่าเป็นร่องรอยที่หลงเหลือจากวิธีการติดตั้งใช้งานปัจจุบัน
    • ถ้ามองเฉพาะผู้ใช้ที่มองเห็น ลำดับปัจจุบันก็ดูสมเหตุสมผล วิธีที่เสนอจะทำให้ต้องเลื่อนขึ้นลงบ่อย ๆ เพื่อดูรายการตามลำดับ และถ้ามีการเพิ่มรายการอีก ก็อาจเกิด การเลื่อนเลย์เอาต์ครั้งใหญ่ ได้
    • ถ้าต้องการเอฟเฟกต์ Masonry ใช้ CSS multi-column layout ที่รองรับกว้างขวางอยู่แล้วไม่ได้หรือ?
    • มันก็เป็นแค่เดโมสุ่ม ๆ และดูไม่ค่อยเกี่ยวกับแนวคิดหลักของการรวบรวมฟีดแบ็กเท่าไรนัก

  • ข้อดีของฟีเจอร์นี้คือ ต่อให้เปิดเดโมในเบราว์เซอร์ที่ไม่รองรับ ซึ่งก็คือเบราว์เซอร์เสถียรทุกตัวในตอนนี้หากไม่ได้เปิดแฟล็กพิเศษ มันก็ยังแสดงผลเป็น รูปแบบแถวคงที่ ที่ค่อนข้างสมเหตุสมผลได้ เพราะสร้างทับบน Grid layout โดยตรง: https://webkit.org/demos/grid3/
    ถ้าเป็น Masonry layout ที่สมบูรณ์จริง ๆ ในแต่ละกรณีก็น่าจะดูดีกว่านี้มาก แต่ถึงไม่เป็นแบบนั้นก็ยังใช้งานได้ดีพอ ถ้าไม่ชอบก็ยังสามารถตรวจจับฟีเจอร์แล้วแสดงผลสำรองที่ดีกว่าได้

  • โดยรวมแล้วหน้าตาและความรู้สึกของ Masonry/เลย์เอาต์แบบน้ำตกนั้นดีมากจริง ๆ อาจเพราะโตมากับการอ่านหนังสือพิมพ์กระดาษและยังอ่านอยู่ เลย์เอาต์แบบคอลัมน์จึงให้ความรู้สึกเป็นวิธีแบ่งหน้าที่เป็นธรรมชาติ
    แต่ก็อยากให้มีทางเลือกอื่นนอกจากการจัดวาง Masonry แบบค่าเริ่มต้น เท่าที่ทราบ กติกาพื้นฐานคือประมาณว่า “วางรายการถัดไปลงในคอลัมน์ที่ยังวางได้สูงที่สุด” ซึ่งทำให้ตั้งแต่แถวที่สองเป็นต้นไป ลำดับซ้ายขวาสลับกันมาก
    วิธีที่นึกภาพว่าอาจดีกว่าคือเลย์เอาต์ที่รักษาทิศทางการอ่าน ซ้าย→ขวา หรือถ้าต้องการ ขวา→ซ้าย ไว้ได้มากกว่า เช่น “นำรายการถัดไปไปใส่คอลัมน์ทางขวาของรายการก่อนหน้า แต่ถ้าอยู่ขวาสุดแล้วก็วนกลับไปซ้ายสุด และถ้าก้นใหม่จะไม่ต่ำกว่าขอบล่างของคอลัมน์ซ้ายมากเกินไป ก็สามารถวางรายการที่สองในคอลัมน์เดิมได้”
    มันยืดหยุ่นกว่าการบังคับซ้าย→ขวาแบบเคร่งครัด จึงทำให้การจัดแนวพังน้อยกว่า และยังคงรักษาความหมายของทิศทางการอ่านซ้าย→ขวาไว้ได้ระดับหนึ่ง
    คงเป็นไปไม่ได้ที่จะรองรับทุกสูตรที่คนอาจต้องการใน Masonry แต่สำหรับคอนเทนต์ที่ลำดับมีความสำคัญอยู่บ้าง ถึงจะไม่ใช่ Pinterest แต่ถ้าเป็นพวกวารสาร ผมคิดว่าวิธีแบบนี้เป็นค่าเริ่มต้นที่สมเหตุสมผลกว่ากฎ Masonry แบบดั้งเดิม

    • ผมจะใช้ Masonry layout เฉพาะกับสิ่งที่แต่เดิมก็ไม่มีลำดับชัดเจนอยู่แล้ว คงไม่ใช้กับภาพที่เรียงตามเวลา
    • ปัญหาอยู่ที่การจัดเรียงซ้าย→ขวาเอง ในเลย์เอาต์แบบนี้แทบไม่มีทางจัดซ้าย→ขวาโดยไม่ทำให้ต้องกระโดดไปมาทั่วหน้า
      ถ้าเป็นเลย์เอาต์แบบนิตยสาร ปกติเราจะอ่านคอลัมน์จากบน→ล่างก่อน แล้วค่อยซ้าย→ขวาไม่ใช่หรือ? ใน CSS ก็ทำได้อยู่แล้วด้วย columns หรือ Flexbox แนวตั้ง
      อีกปัญหาหนึ่งของ Masonry layout นี้คือด้านล่างไม่เรียบเสมอกัน ถ้าเป็นนิตยสารก็คงจัดให้เท่ากัน ซึ่งก็ทำได้ด้วยคอลัมน์หรือ Flexbox เช่นกัน
      ดูเหมือนบนเว็บจะมีสมมติฐานแฝงว่าคอนเทนต์เลื่อนได้ไม่สิ้นสุด จึงมองว่ารูปร่างของด้านล่างหน้าไม่สำคัญ ถ้าอย่างนั้นก็ไม่แน่ว่าจะเป็นสมมติฐานที่ควรสนับสนุนนัก
    • แบบนี้เป็นอย่างไร:
      { /* เมื่ออัปเดต ให้ย้ายองค์ประกอบไปทางซ้ายหรือขวาได้สูงสุด 2 คอลัมน์ */ grid-template-max-horizontal-shift: 2 col; }

  • ถ้าจะสร้าง ระบบที่ไม่ต้องรองรับความเข้ากันได้ย้อนหลัง เพื่อมาแทนที่ CSS ได้ เราควรทำอย่างไร?
    มีหนังสือหรืองานวิจัยเกี่ยวกับวิธีสร้างระบบเลย์เอาต์ที่สอดคล้องกันหรือไม่?
    ทางเลือกอย่าง Qt, Tk, SwiftUI เป็นอย่างไร? นอกจาก CSS แล้วไม่เคยใช้อะไรอย่างอื่นเลย ถ้ามีระบบที่ถูกนำไปใช้แพร่หลายและดีกว่าจริง มันดีกว่าเพราะอะไร?
    อยากได้ระบบที่ให้อินเทอร์เฟซที่ดีกว่าสำหรับนักพัฒนา แต่ไม่รู้ว่าควรทำอย่างไร ถ้าเริ่มออกแบบใหม่ตั้งแต่ต้น หลักการออกแบบควรเป็นอะไร?

    • ไม่ได้ต่อต้าน CSS เป็นพิเศษ แต่แนวคิดอย่าง กลุ่มขนาด, วงจรการร้องขอ-จัดสรรขนาดที่คาดเดาได้, ความกว้างที่ขึ้นกับความสูง, และเลย์เอาต์แบบอิงข้อจำกัดและการจัดแนว น่าจะเป็นเรื่องที่ควรสนใจ และโดยรวมแล้วควรจัดระเบียบความสับสนของแนวคิดต่าง ๆ ใน CSS ที่พันกันแบบไม่เป็นอิสระต่อกัน
      พร็อพเพอร์ตีควรชัดเจนและแยกจากกันมากกว่านี้ ควรกำจัดอะไรเพี้ยน ๆ อย่าง negative margin ไป และทำให้ระยะทั้งหมดเป็นแบบหลายชั้น ตัวอย่างเช่น padding = max(el.paddings[])
      กล่องขอบเขตควรถูกสร้างอย่างชัดเจน และเส้นขอบควรเป็นองค์ประกอบที่ถูกต้อง Box model เองไม่ได้แย่ แต่ CSS ทำให้การนำไปใช้แย่มาก เต็มไปด้วยคาถาเปราะบางที่แตะเมื่อไรก็พัง 99% และข้อจำกัดประหลาด ๆ ซึ่งข้อจำกัดเหล่านั้นก็ยิ่งสร้างปัญหาและ “วิธีแก้” เพิ่มขึ้นอีก
    • เลย์เอาต์แบบอิงข้อจำกัดที่ใช้ อัลกอริทึม Cassowary เคยดูเหมือนจะเป็นทางเลือกยอดนิยมอยู่ช่วงหนึ่ง: https://github.com/slightlyoff/cassowary.js/?tab=readme-ov-f...
      มันถูกออกแบบมาเพื่อแก้ปัญหาการเปลี่ยนแปลงของขนาดและรูปทรงหน้าจอ Apple ย้ายไปใช้ SwiftUI แล้ว และอาจจะก้าวข้ามแนวทางนี้ไปแล้วก็ได้
    • ถ้ามีบทความที่เปรียบเทียบระบบการจัดสไตล์/เลย์เอาต์หลายแบบก็น่าจะน่าสนใจมาก เพียงแต่คนที่เคยผ่านภาษาสำหรับจัดสไตล์หลายแบบจริง ๆ อาจมีไม่มาก เลยอาจมีคนที่เขียนบทความแบบนั้นได้ไม่มากนัก
      Flutter และ XAML ก็น่าจะเป็นสิ่งที่ควรลองดูด้วย
    • สิ่งที่ต้องระวังเวลาเลือกกรณีตัวอย่างมาอ้างอิงคือ CSS ตั้งมาตรฐานของ การควบคุมแบบประกาศ ไว้ค่อนข้างสูง แม้จะพูดรายละเอียดของตัวอย่างที่ถูกกล่าวถึงไม่ได้มากนัก แต่กรณีอ้างอิงที่เทียบเคียงได้มากกว่าน่าจะพบได้จากงานฝั่งสิ่งพิมพ์
    • สำหรับหนังสือคลาสสิกในหัวข้อนี้ ดูเหมือนว่าจะมี "Rastersysteme für die visuelle Gestaltung - Grid systems in Graphic Design" ไม่ได้เคยอ่าน

  • โพสต์ซ้ำเป็นคอมเมนต์ระดับบนสุดเพื่อให้มองเห็นได้ชัดขึ้น
    ผมมีเว็บไซต์ภาพถ่ายอยู่เว็บหนึ่ง และไม่ได้ใช้ JavaScript กับเลย์เอาต์ ตอนทำเคยพิจารณา JavaScript Masonry library แต่ผลลัพธ์ไม่น่าพอใจ
    Masonry layout ที่ “ถูกต้อง” แบบที่เติมพื้นที่ใช้งานทั้งหมดจริง ๆ จะต้องครอปภาพบางส่วนออก ถ้าจะไม่ครอปและยังคงอัตราส่วนเดิมไว้ ก็ต้องปล่อยพื้นที่ว่างรอบรูป วิธีเดียวที่จะไม่ต้องทำแบบนั้นคือ infinite scroll ซึ่งอาจเป็นสิ่งที่เครื่องจักรสร้างการเสพติดของบริษัทยักษ์ใหญ่ต้องการ แต่ไม่ใช่สิ่งที่ผมต้องการในเว็บไซต์ของตัวเอง
    ผมทำออกมาแบบนี้:
    https://yakubin.com/photography/albumless/
    https://yakubin.com/photography/album/kenya-2023/
    เพื่อให้ได้ผลลัพธ์นี้ ผมใช้ display:inline-block และปฏิบัติต่อภาพเหมือนข้อความที่ควรถูก reflow ไปขึ้นบรรทัดใหม่ ผมพอใจกับผลลัพธ์มาก และชอบมากกว่าวิธีที่ Masonry library ทำ

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

  • เกี่ยวกับเรื่องนี้ ผมได้ทำเดโมแบบอินเทอร์แอ็กทีฟที่อธิบายหลักการของ Grid ไว้:
    https://cssprinciples.com/3/grid/

  • มีทั้ง float แบบเดิมอยู่แล้ว และก็มีเลย์เอาต์สมัยใหม่อย่าง Flexbox กับ Grid เลยสงสัยว่าการเพิ่มตัวเลือก “เลย์เอาต์” เข้าไปใน CSS เรื่อย ๆ ยังเป็นแนวทางที่ถูกต้องหรือไม่
    ถ้ายังมีกรณีที่ครอบคลุมไม่ได้อยู่ บางทีทางออกที่ดีกว่าอาจเป็นการมี ระบบแบบอิงข้อจำกัด ขั้นสุดท้ายเพียงตัวเดียวที่ครอบคลุมกรณีเลย์เอาต์ทั้งหมด แม้จะซับซ้อนขึ้นก็ตาม แบบนั้น CSS framework และ utility library ก็สามารถสร้าง Masonry Grid ยุคถัดไปและอย่างอื่นบนฐานนั้นได้

    • ค่อนข้างสงสัยว่าระบบแบบอิงข้อจำกัดจะถูกพิจารณาจริงหรือไม่ จนถึงตอนนี้ CSS เน้นเรื่องความสามารถในการคาดเดาต้นทุนของการจัดเลย์เอาต์อย่างมาก
      ถึงอย่างนั้นข้อเสนอ Houdini layout ก็ใกล้เคียงกับแนวคิดนี้ที่สุด โดยเป็นวิธีส่งงานเลย์เอาต์ไปยัง JavaScript context ที่แยกออกมา: https://github.com/w3c/css-houdini-drafts/blob/main/css-layo...
      แต่พูดตามตรง Flexbox, Grid และสิ่งอย่าง containment ก็แก้ปัญหาไปได้มากแล้ว เลยมีความต้องการให้ปรับปรุงน้อยกว่ายุคก่อน Flexbox มาก
    • แก่นของความเคลื่อนไหวนี้คือการเลิกใช้ float hack เก่า ๆ หรือ hack ของ CSS Grid/Flexbox ที่เดี๋ยวก็จะล้าสมัย Masonry layout ของ Firefox ใช้วิธีเพิ่มพร็อพเพอร์ตีใหม่ตัวเดียวเพื่อพับแถวของ Grid ดังนั้นในทางปฏิบัติจึงถูกทำมาให้ครอบคลุมกรณีเลย์เอาต์แทบทั้งหมด
    • นี่คือ Grid Level 3 สามารถทำแบบนี้ได้:
      display: grid;
      grid-template-rows: masonry;
      แต่จำกัดอยู่ที่ WebKit เท่านั้น เคยเอาไปใช้กับโหมดแกลเลอรีของฟีดข่าวส่วนตัว แล้วก็เลิกใช้ไปแล้วตั้งแต่เดือนตุลาคม 2023
    • JavaScript คือระบบเลย์เอาต์ขั้นสุดท้าย ไม่มีภาษาเชิงประกาศไหนรองรับ use case ได้ทั้งหมด โชคดีที่หลังจากมี Grid แล้ว ก็แทบไม่จำเป็นต้องพึ่ง JavaScript
      ระบบแบบอิงข้อจำกัดน่าจะไปอยู่แบบก้ำกึ่งระหว่าง Grid กับ JavaScript อย่างดูแปลก ๆ เลยไม่แน่ใจว่าจะช่วยได้มากแค่ไหน
    • ถ้ามีความต้องการที่ CSS layout ไม่รองรับโดยตรง ก็สร้าง เลย์เอาต์ด้วย JavaScript ได้เสมอ

  • ใช้อยู่แล้ว ใน Firefox เปิดจากตัวเลือกแล้วเอามาใช้กับบุ๊กมาร์ก บนมือถือมันก็แค่เรียงซ้อนลงมาตามปกติ เลยไม่มีปัญหา บนมือถือไม่มี about:config
    รูปสุดท้ายคือสถานะตอนปิดไว้
    https://imgur.com/a/o7OyZEW

    • เท่าที่เข้าใจ กฎของ Masonry layout จะเติมช่องว่างที่อยู่สูงที่สุดก่อนในระดับแถว เลยทำให้เกิดการจัดเรียงที่ไม่สม่ำเสมอ แต่ในเชิงภาพจะดูเหมือนจัดเรียงตามคอลัมน์
      ดังนั้นถ้าปรับขนาดหน้าต่าง ลำดับของบุ๊กมาร์ก ก็น่าจะเปลี่ยน
    • ลองใช้ Firefox Beta บนมือถือดู :)

  • ถ้าอยากดูบริบทเพิ่มเติมและข้อโต้แย้งอีกฝั่งหนึ่ง ว่าทำไม display: masonry ถึงดีกว่า display:grid + grid-template-rows: masonry สามารถดูการอภิปรายอย่างละเอียดได้ที่นี่: https://github.com/w3c/csswg-drafts/issues/9041