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

Original Article ↗ Hacker News Discussion ↗

Browser vendors are experimenting with adding a “masonry” or Pinterest-style layout as part of CSS Grid Level 3, allowing items of varying height to automatically pack into columns without gaps. Supporters argue this should be a native, declarative feature for performance, accessibility, and simpler code, rather than relying on JavaScript libraries or layout hacks. Critics question whether masonry is common or usable enough to justify the added complexity, and debate whether it should extend `display: grid` or exist as a separate layout mode.

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.