logo

CSS Masonry のあゆみと現状

Published on

Updated on

CSS Masonry（Grid-Lanes）の仕様策定の経緯と現状のまとめ

Table of Contents

Table of Contents

はじめに

2025 年は、Pinterest に代表される「Masonry レイアウト」の仕様の策定が、大きな進展を見せた年だったように思います。

Grid 以降で初めて本格的に最重要概念の「レイアウト」に手を加えた提案として、我々にとっては無視し難いトピックの一つでありながら、CSS Masonry は議論が本格化してから比較的長期に続いているプロジェクトでもあります。

しかし、その議論の長期戦はあるべくして起こったものであり、そこから学び取れる示唆も少なからずあったと筆者は考えています。

今ここで一度何があったかを整理して理解した上で今後の動向を正しく追っていくために、ここにまとめを記します。

（※ 本エントリは「Masonry のそもそも」やユースケースを説明する趣旨ではないので紹介は割愛します。 既出の記事を参照ください。 e.g, “What is masonry layout?” - Help us invent CSS Grid Level 3, aka “Masonry” layout | WebKit）

CSS Masonry を振り返る

今回の Masonry レイアウトの始まりは、以下の提案が WG に持ちかけられたときと捉えることにします。

当時、Grid Layout の第一人者である Rachel Andrew が、「Pinterest のようなレイアウトを CSS でやりたい」という開発者側の声を CSS WG に届けたのがきっかけだったようです。

CSS Houdini Layout API

この提案が出たあたりは、ブラウザがまだサポートしていないレイアウト（Masonry 含む）は開発者自身で作れるようにする、CSS Houdini の Layout API が夢の技術として期待されていました。

しかし、 パフォーマンスや Houdini の成熟度の観点から、 Masonry は Gridの一部としてネイティブにサポートされるべき、 という方向へ話が流れることになります。

Grid ベースとして黎明したネイティブ CSS Masonry / grid-template-*: masonry; & masonry-auto-flow

Layout API の文脈から外れて、 CSS Masonry の標準化作業が始まったのは、以下の Issue が最初でした。

「CSS Grid の一軸を通常の Grid（行や列がある）: Grid Axis とし、もう一方の軸を Masonry（行や列の概念がなく、詰めて配置）: Stacking Axis にする」というのが、 初期 Masonry レイアウトの考え方です。
よって、初期では Grid（display: grid | inline-grid）をベースとしながら、 Masonry を有効化する方法が提案されていました。軸を取り消すための masonry キーワードを grid-template-[rows | colums] へ追加し、これを指定すると Masonry にスイッチする提案です。

Grid ベース masonry の仕組み

例えば、高さや幅が一定の Grid Axis（e.g, Columns）を grid-template-columns で定義し、高さや幅が一定でない Stacking Axis（e.g, Rows） には masonry （要素を敷き詰め）を指定すると、 Pinterest のようなレイアウトが実現できます。
加えて、 masonry-auto-flow: [ pack | next ] || [definite-first | ordered ] で、アイテムの積み上げ方を制御する案も出されていました。

これを最初に定義したドラフト（CSS Masonry Layout Module）が、 Wayback Machine で一件だけヒットしたため、記録として掲載しておきます。

もちろん文法は全く異なりますが、2025年現在の CSS Grid Layout Module Level 3 はこのドラフトに記載の概念をかなり踏襲していることが分かります。

実装としては、以下のようなものが想定されていました。

<style>
.masonry {
  display: grid;
  grid: masonry / repeat(3, 2ch);
  /* ↑ same as below ↓ */
  /* grid-template-rows: masonry; */
  /* grid-template-columns: repeat(3, 2ch); */
  border: 1px solid;
  masonry-auto-flow: pack;
}

.item { background: rebeccapurple }
</style>
<div class="masonry">
  <div class="item">1</div>
  <div class="item">2</div>
  ...
</div>

このように、 display Grid をベースとして、 grid-template-* で Masonry にスイッチするというのが基本的な考え方でした。よって、ここからは便宜上、こうした Masonry 仕様を 「Grid ベース」 と表記します。

そして、議論の結果、この案は CSS Grid Layout Module Level 3 の一部として作業が進められていくことになります。

Firefox でのフラグ付き実装と Safari TP での実装

これを受けて、 Firefox では 2020 年にフラグ（grid-template-masonry-value）付きで Masonry レイアウトが実装されていました。
この時点で実装されていたのは、 Grid ベース Masonry です。

その後、 Safari TP でも実装が入ることになります。ただ、これが Stable に落ちてくることはなかったということになります。

ここまでで、Grid ベース として Masonry の仕様策定が進み、 Firefox と Safari TP の 2 ブラウザで実装が進んでいる状態でした。「このまま Grid Level 3 としてリリースされる」と思われていた矢先、風向きが変わることになります。

「Grid ベース」 か 「display: masonry」 か - “Just Use Grid” or “New Masonry Layout”?

2023 年 7 月、Chrome の Ian Kilpatrick が、Grid ベースではなく独立した display: masonry を提案する Issue を立ち上げました。

提案された構文は以下のようなものです。

display: masonry;
masonry-template: repeat(auto-fill, auto);
masonry-direction: column-reverse;
masonry-span: 2;
masonry-threshold: 2px;

提案の背景としては、Grid と Masonry の Sizing 計算の違いにありました。
Grid は子要素を 2D Grid に配置してからサイズを決定します。つまり、詰めるモノも詰める場所も決まっているので、 問題なく内在サイズを計算できます。一方 Masonry は詰める場所が詰めるモノのサイズに依存し、詰めるモノの内在サイズは詰める場所によって決まるというニワトリタマゴの状態になり得ます。

Rachel Andrew もこの提案を支持し、「Grid に Masonry を含めることに賛成したことはない。新しい Grid 機能を追加するたびに、それが Masonry でどう動くかを永遠に考え続けなければならなくなる」といったコメントをしています。

一方で、Masonry を Grid から分離すると、 Track 幅の可変性や Subgrid といった Grid の恩恵を受けられなくなります。

そして、この提案を契機に陣営の明確化が始まります。

WebKit: Grid ベース Masonry

この議論の進捗に対して、WebKit として初めて見解が出たのが、以下の記事です。

主張を簡単にまとめると以下のようになります。

Masonry はあくまで 「Grid レイアウトの一形態（一方の軸を定義しない 「Grid」）」 とすることで Grid の特性を活かせるようにすべき、と位置づけたのが WebKit 陣営の主張でした。

Chrome: display: masonry

そこに切り返すように、Chrome から出たブログが以下です。

… implementing it as part of the CSS Grid specification as proposed in the recent WebKit post would be a mistake.
… this post aims to explain why we at Chrome have concerns about implementing masonry as part of the CSS Grid Layout specification, and clarify exactly what the alternate proposal enables.

WebKit の主張は間違っており、WebKit が捉えた Chrome の立場も正確ではないため、この場を以て訂正する、といったものでした。

主張を簡単にまとめると以下のようになります。

つまり、無理に Grid に統合して沸き立つ複雑さや誤解を避け、専用のプロパティセットを持つクリーンな仕様を提案すべきというのが Chrome 側の主張でした。

Chrome の実装

そして、 この主張を取り入れた display: masonry を試験的に提供し始めることになります。開発者フィードバックを得るための材料として必要な実装だったことは、直後に出されたブログ記事からも読み取れます。

Syntax に関する議論は膠着状態となり、TAG のデザインレビューを交えた WG でのディスカッションや、 Telecon でのプレゼンが繰り返されます。

外から見ると、Jen Simmons と Rachel Andrew という、ともに Grid を主導してきた二人の対立に映ったかもしれません。
しかしこれは、レイアウトの未来を真剣に考えるからこその、建設的な議論であり、この議論がなければ今の Masonry のデザインは生まれなかった、然るべきリソースの投入だったと筆者は考えています。

「レイアウト」という CSS 根幹のメンタルモデルに対するスタンスの表明は、市場にも相当なインパクトをもたらすものです。そういった類の議論が、特に慎重に何重もの検討を重ねられ、時間をかけて熟されてきたことは、Flexbox や Grid に重なる部分があります。
最初のモダンレイアウトアルゴリズムとして登場し、今ではほとんどの Web サイトが利用していると言ってもいい Flexbox でも、複数の異なる構文が同時に存在した時期を経験しています。その後の Grid は、Flexbox で下された設計判断の多くを見直す機会にもなりました。
Flexbox Level1 が何度も Revision を重ねていることは、その証左でしょう。

Masonry はこの 15 年以上にわたるレイアウトの蓄積から恩恵を受け、またより良い設計に進化させるための触媒にもなり得ます。だからこそ、議論の焦点が単に仕様の曖昧さを埋めることにとどまらず、より高いレベルの設計議論へと移っていったのはある意味自然な流れです。
Flexbox と Grid の特性を統合する 「Item Flow」 というアイデアが生まれたのは、この蓄積があるからこそ生まれたものなのだと思います。

ItemFlow という転換点

議論が膠着状態の中、TAG のデザインレビューを経て、新たな概念として浮上したのが、「Item Flow」です。

簡単にいうと、Item Flow は、Flexbox の flex-flow と Grid の grid-auto-flow を統一する新しいプロパティ群です。これにより、Flexbox、Grid、Masonry という 3 つのレイアウトモデルを、共通の語彙で説明できるようになります。

具体的には、以下の概念で構成されます。

詳しくは、以下の WebKit ブログ記事に写真付きで解説されています。

Masonry は、この Item Flow の観点から見ると「行または列を collapse（崩す）するレイアウト」として表現できます。display: masonry という新しい値を導入するのではなく、既存の Grid に item-flow: row collapse を指定することで Masonry レイアウトを実現する、という発想です。

.masonry {
  display: grid;
  grid-template-columns: repeat(auto-fill, minmax(14rem, 1fr));
  item-flow: row collapse;
  gap: 1rem;
}

Flexbox と Grid でバラバラに存在していた flex-flow と grid-auto-flow を統一し、さらに Masonry という新しいレイアウトモデルまで包含して、より抽象度の高い設計への転換する。単なる妥協案だとは捉え難い素晴らしい提案だと思います。

そして、Item Flow は Masonry だけのものではありません。Flexbox にも item-pack: dense（前の行の空きスペースに Item を詰める）や item-pack: balance（text-wrap: balance のように各行の Item 数を均等化）といった待望の機能が検討されています。Grid も item-wrap: nowrap（折り返さない単一行 Grid）が可能になります。

蓋を開けると、Chrome と WebKit の対立は、Item Flow という新しい概念を生み出す触媒になっていました。どちらの提案が「勝った」ということはなく、議論を通じてより良い道が見えた、というのが現時点での状況です。

The State of CSS Masonry Grid-Lanes

ここまでの議論の結果、 Masonry に関して決着がついたこと、ついていないことそれぞれあるので、まとめておきます。

✅ Item Flow の導入

Item Flow という概念は、結果として WG でも採用され、これによって Masonry Item の Flow を定義することが決まりました。

前述しましたが、 Item Flow によって、Flexbox、Grid、Masonry 含むあらゆる 「Items-in-container」のモデルを、共通の語彙で説明できることが目標とされています。

RESOLVED: Continue to work on the item-* props as a set of switches for all items-in-container layout modes
RESOLVED: Put it in grid-3 for now, with intention to move
https://github.com/w3c/csswg-drafts/issues/11480#issuecomment-2628118101

ただし、 Item Flow の構文はについてはまだ決着がついておらず、それは後述します。

✅ css-grid-3 に含め、grid-* 構文を利用する

Item Flow の採用と同時に、 Masonry 専用のレイアウトモデルを新規に作成することはなくなり、Masonry の Syntax には grid-* 記法を利用することで合意が取られました。

RESOLVED: Re-use grid templating and placement properties for masonry layout
https://github.com/w3c/csswg-drafts/issues/11243#issuecomment-2627998471

✅ Masonry Container を定義する grid-template-[rows | columns]

ということで、grid-template-[rows | columns] を Masonry の Templating を定義することにも再利用します。

再掲ですが、grid-template-rows: masonry など新しいキーワードが生まれるわけではなく、 grid-template-rows: repeat(auto-fill, <track-size>) のように、既存の Grid の記法で Masonry コンテナを定義することになります。

✅ display: grid-lanes で Masonry を有効化

ただし、 2020年当時検討＆一部実装されていた display: grid の Gird ベースを「そのまま」 利用するわけではありません。
grid-template-* など Grid のプロパティセットを活かしつつ、 「Masonry は Grid のような完全な２次元モデルではない」という Google 側の主張を取り入れ、 Masonry 用の display キーワードを導入して切り替えることになりました。（ただし、Grid との乖離を生まないよう、キーワードに grid を含めることが条件）

RESOLVED: Switch for masonry will be a new display type. Display type must include the word grid in the name. We will open an issue for the exact name.
https://github.com/w3c/csswg-drafts/issues/12022#issuecomment-3200131437

Poll の結果 grid-lanes が選ばれ、これで Flexbox でも Grid でもない新しいレイアウトモデルが誕生したことになります。

RESOLVED: masonry switch will bedisplay: grid-lanes
https://github.com/w3c/csswg-drafts/issues/12022#issuecomment-3525043825

ここは少し筆者の解釈が入りますが、grid-lanes という命名について説明しておきます。Masonry レイアウトは一方に等幅の track を持つという特徴がありました。つまり、通常の Grid が 2D のセル構造を持つのに対し、Masonry は 単軸 Grid の「レーン」構造とイメージすることができます。

A basic masonry layout with consistent track sizes and no spanning can look a lot like a flex layout, but the layout system we’re designing here is reallya “one-axis grid” system.
https://github.com/w3c/csswg-drafts/issues/12022#issuecomment-3597670490

この概念と最も一致していたのが grid-lanes だったため、筆者もこれに vote しました。

道路の車線（レーン）に Masonry の track を見立てる

道路の車線（レーン）に Masonry の track を見立てる: picture source - Brick by brick: Help us build CSS Masonry  |  Blog  |  Chrome for Developers

この名称がどこまで適用されていくのかは不明ですが、 WG 内で 「Masonry」 と呼ばれていたものは今後「Grid-Lanes」として扱われるようになっていくのかもしれません。

CSSWG Masonry Breakout

CSSWG Grid-Lanes Breakout

世間一般としてこの名称が浸透していくかはわかりませんが、仕様に基づいた言及が尊重される局面においては、「Grid-Lanes」を使うようにしようと思います。

ここまでで諸々の方針が決まりましたが、重要な Item Flow の詳細詰めがまだできていません。
これからの主要な Masonry の議論は、 Item Flow の議論と言ってもよくなってきているため、 Item Flow の現状についてまとめておきます。

Rows vs Columns: flex-flow + grid-auto-flow and masonry layout

Flexbox と Grid だけではなく、 Masonry もカバーするということで、Item Flow の row と column の解釈が一筋縄ではいかないというのが、最初にして最大の論点となっています。

Flexbox では、flex-flow: row wrap は「アイテムが横方向に並び、折り返す」レイアウトを意味します。Grid でも grid-auto-flow: row は行方向への自動配置を指します。つまり、どちらも下図で言うレイアウトの「Shape」と「Flow」が一致しています。 Row の Flow であれば、 Row の Shape、 Column の Flow であれば Column の Shape ということです。

しかし Masonry では事情が異なります。Pinterest では、見た目「Shape」は「縦」に積み上がる「Column」ですが、アイテムの「Flow」は各カラムの一番短いところへ横向きの「Row」に次々と配置されていきます。

Shape of Layout
Shape of Layout: source - Masonry & item-flow

Flow of Layout
Flow of Layout: source - Masonry & item-flow

では、この waterfall レイアウトは item-flow: row なのか item-flow: column なのか？「Shape」で考えれば Columns、「Flow」で考えれば Rowとなります。

この「Shape」と「Flow」が一致しないのが Masonry の特徴でもあり、 この解釈の違いが Item Flow の議論のブロッカーとなっています。逆にいうと、これが決着すれば芋蔓式に解決する問題が残っているのが現状です。

  1. Whether we’re re-using grid-auto-flow or adding a new masonry-specific set of properties for this.
  2. What the values map to.
  3. Naming the initial automatic value that flips depending on grid-template-*.
    https://github.com/w3c/csswg-drafts/issues/12803#issuecomment-3528390437

現時点では、 この Issue 内のそれ以外の RESOLUTION はすでに出ています。

1. Item Flow と既存の flex-flow や grid-auto-flow との関係

Item Flow と既存の flex-flow や grid-auto-flow との関係をどう整理するかが議論され、これはすでに結論が出ています。

「1. 互いにエイリアスとして振る舞うよう扱う」「2. Item Flow を他の Shorthand として扱う」「3. Item Flow をMasonry 専用の Shorthand として扱う」 が検討された結果、Option 2: Flex + Grid/Masonry Longhands が採用されています。

つまり、Flex/Grid 既存のプロパティは互いにエイリアスとして機能する訳ではなく、Masonry 専用のプロパティセット（masonry-flow など）を新たに導入することもなくなりました。

3. 初期値の定義

grid-lanes の初期値についても、最近決着がついています。

RESOLVED: Whatever property controls the orientation of grid-lanes, its initial value is ‘normal’ and it resolves to waterfall or brick layout depending on whether grid-template-columns or grid-template-rows was set (respectively), defaulting to waterfall if both or neither are set.

つまり、方向を制御するプロパティの初期値は normal で、これは grid-template-columns が設定されていれば Waterfall Masonry、grid-template-rows が設定されていれば Brick Masonry になる、ということを示します。

２(Rows vs Columns)とそれに関連した issue については、引き続き議論されなければならず、関連した issue も未解決な状態です。

Reversing: column/row-reverse vs wrap-reverse

Masonry には「Grid Axis」（Track が定義されている軸）と「Stacking Axis」（Item が積み上がる軸）があります。

Flexbox では flex-direction: row-reverse と flex-wrap: wrap-reverse という 2 種類の reverse があります。Item Flow でこれを統一する際、Masonry ではどちらの軸が反転するのでしょうか。

row-reverse / column-reverse は Grid 軸を反転させるのか、それとも Stacking 軸を反転させるのか。wrap-reverse はどちらなのか。

Flexbox や Grid では直感的に理解できた 「reverse」の挙動が、Masonry の 「Shape と Flow の不一致」 という特性により、定義が難しくなっていることがわかります。

Property Names

プロパティの命名についても複数の選択肢が検討されています。

やはり、これも Rows vs Columns の決着によって動く類の議論であり、 item-flow というプロパティ名自体も大いに変わる可能性があります。

Demo

変わる可能性は大いにありますが、現状を反映したデモを用意しています。

Chromium では grid-lanes がすでに実装されており、Canary で #enable-experimental-web-platform-features フラグを有効化して試せます。（2025年12月07日現在）
また、 Safari の Stable でも近日中に grid-lanes が有効化される予定です。

各エンジンの実装状況については、以下の bug から確認できます。

おわりに

Grid-Lanes の議論を振り返ると、機能が互いに影響し合いながら進化していくの過程を垣間見ることができます。

Flexbox が最初のモダンレイアウトアルゴリズムとして多くの試行錯誤を経験し、その教訓が Grid に活かされ、そして今、Grid-Lanes はその 15 年以上の蓄積の上に立っています。
「Flexbox のときは理にかなっていたような多くの設計判断が、より一般に適用しようとすると変更が必要になった」ことは、今まさに Item Flow で起きていることと重なります。

そしてその過程には必ずと言っていいほど対立する意見が存在し、合意形成のために莫大なリソースが注がれます。しかし、その過程がなければより良い設計は生まれなかったこともまた事実で、これこそが、標準化プロセスを経る価値なのだと思います。
Masonry だけだった議論が、Masonry を包含した概念を産んだことで、まだ Web で見なかったレイアウトが生まれてくる可能性があってもおかしくないのです。

まだ名前が決まったわけではありませんが、Item Flow がブラウザに実装された暁には、あのとき「Pinterest のようなレイアウトを CSS でやりたい！」と声を上げた人と、その声を WG に届けた Rachel のことを思い出してしまう気がします。

Appendix