Help us invent CSS Grid Level 3, a.k.a. "Masonry" layout

Original Article ↗ Hacker News Discussion ↗

Overall sentiment

  • Many are excited to see native “masonry” support; others find the layout niche, bad UX, or not worth spec complexity.
  • Broad agreement that standardizing a frequently hand-rolled pattern has value, but sharp disagreement on how and whether to do it.

Perceived benefits & use cases

  • Common “Pinterest‑style” / image gallery layouts; designers frequently request it.
  • Useful where items are independent and order is not critical (photo walls, cards, bookmarks).
  • Native CSS keeps content usable in non‑supporting browsers (falls back to normal grid) and avoids JS layout failures or layout shifts.
  • Integrating with Grid lets masonry reuse columns, gaps, subgrid, track styling, etc., and enables mixing manual placement with auto masonry.

Concerns about UX & accessibility

  • Masonry can destroy expected reading order and tab order, especially when used for text or menus.
  • Several demos (e.g., megamenu, newspaper) are criticized as misleading or poor examples; multi‑column with break-inside: avoid is suggested instead.
  • Some users find masonry and infinite scroll together frustrating for systematic scanning.

CSS vs JavaScript / Houdini

  • Pro‑CSS: JS layout is slower, more power‑hungry, single‑threaded, harder to debug, and has no good no‑JS fallback; layout should be declarative.
  • Pro‑JS/constraints: Layout is inherently complex; not every pattern belongs in CSS. Better to expose general layout APIs (e.g., Houdini layout, workers, WASM) and let libraries implement masonry variants.
  • Houdini is cited as the “escape hatch,” but support is currently poor.

Grid vs new display type

  • One camp: masonry should be a Grid Level 3 feature (e.g., grid-template-rows: masonry|off), so all future grid features automatically apply to both modular and columnar grids.
  • Other camp: masonry is not a true grid; it behaves more like flex or columns and deserves its own display: masonry (or better‑named) model, avoiding overloading an already complex Grid spec.
  • Fallback behavior is discussed: separate display could still degrade gracefully via multiple display: declarations or @supports.

Performance, complexity, and alternatives

  • Worries about quadratic or worse algorithms when masonry is layered onto Grid’s sizing rules, especially with nesting.
  • Some argue CSS is already overly complex; every new layout mode is a maintenance and implementation burden.
  • Others note multi‑column layouts, flexbox, inline-block, or server‑side/JS solutions can approximate masonry, though ordering and resizing behavior are often inferior.
  • Naming (“masonry” vs “columnar grid”/“flex‑grid”/“mosaic”) is debated; many expect the final keyword to change.