カード型UI。高さがバラバラ。写真も文章も混ざる。
そうなると必ず出てくるのがPinterest風レイアウト、いわゆるMasonryです。
今まではJavaScriptで高さを計算したり、カラムを分割したり、Gridをだましだまし使ったりしてきました。正直、どれも一長一短。軽くはないし、実装も美しくない。
そんな中で登場したのが、Native Masonry。CSSだけで、あのレイアウトをブラウザ自身に任せてしまおうという発想です。
夢みたいな話に聞こえますか。私も最初はそう思いました。
この記事では、Native Masonryとは何か、なぜ今までの方法を一度止める価値があるのか、どうやって使うのか、メリットとデメリット、そして現場でどう扱うべきかを、かなり率直に書きます。
フロントエンドを勉強している人にも、毎日コードを書いている人にも、どちらにも刺さる話です。
そもそもMasonryレイアウトは何が面倒だったのか
Masonryは見た目が気持ちいい。だが実装はあまり気持ちよくない。
これが長年の本音ではないでしょうか。
JavaScript依存という重さ
代表的なのはMasonry.js系ライブラリ。DOMを取得し、高さを測り、位置を計算し、再配置する。
初期表示が遅れる。画像の読み込み順でレイアウトが揺れる。リサイズ時に再計算が走る。
軽量とは言い難い。
CSSカラムによる妥協
column-countやcolumn-widthを使う方法もありました。
ただし、縦方向に流れる。左から右ではなく、上から下。
順番が崩れる。アクセシビリティも微妙。クリック時の体験も直感的ではない。
Gridでの疑似Masonry
grid-auto-rowsとspanを使った疑似実装。これもよく見ます。
ただし、高さ計算が結局必要になる。JSを完全に捨てられない。
つまり、Masonryはずっと中途半端な存在でした。
見た目は欲しいが、実装は妥協の連続。これを何年も続けてきたわけです。
Native Masonryとは何者か
Native Masonryは、CSS Gridの拡張として提案されている機能です。
ざっくり言うと、ブラウザが高さを勝手に判断し、最適に詰めてくれる仕組み。
JS不要。DOM操作不要。CSSだけ。
ポイントはgrid-template-rows: masonry
従来のGridでは、行の高さは明示的に定義する必要がありました。
Native Masonryでは、これをmasonryにします。
.container {
display: grid;
grid-template-columns: repeat(auto-fill, minmax(200px, 1fr));
grid-template-rows: masonry;
gap: 16px;
}
たったこれだけ。
カードの高さは中身次第。ブラウザが勝手に詰めてくれる。
正直、初めて見たときは拍子抜けしました。
なぜ今までの方法を一度止める価値があるのか
止める必要がある、という言い方をしましたが、正確には「一度立ち止まって考える価値がある」です。
理由1 実装コストが激減する
JSライブラリ導入。初期化コード。リサイズ対応。画像ロード監視。
これらが一気に消えます。
CSS数行で終わる。これは革命に近い。
理由2 パフォーマンスが素直
レイアウト計算をブラウザに任せるということは、最適化をブラウザチームに任せるということです。
自前JSでやるより、まず負けません。
理由3 保守性が異常に高い
JSがないということは、壊れる場所が減るということ。
仕様変更に怯える回数も減る。
ここで一度、自分に問いかけてみてください。
そのMasonry、本当にJSである必要ありますか。
やり方 基本構文と最低限の条件
やり方自体は驚くほどシンプルです。
HTML構造
.........
特別な構造は不要。フラットでOK。
CSS基本形
.container {
display: grid;
grid-template-columns: repeat(auto-fill, minmax(240px, 1fr));
grid-template-rows: masonry;
gap: 24px;
}
item側は普通に書く。
.item {
background: #fff;
border-radius: 8px;
}
これだけです。
注意点
Native Masonryはまだ新しい。全ブラウザ対応ではありません。
ここで、止める判断が必要になります。
対応状況と現実的な使いどころ
理想と現実は違う。
これはフロントエンドの基本法則です。
対応ブラウザの現状
現時点では、実験的実装が中心です。
安定して使えるとは言い切れない。
だからこその使いどころ
- 管理画面や社内ツール
- 実験的なLPやキャンペーン
- 対応ブラウザを限定できる環境
逆に、コーポレートサイトや広範囲ユーザー向けでは、まだ様子見が無難。
今すぐ全置き換え、は危険です。
フォールバック設計が前提になる
Native Masonryを使うなら、フォールバックは必須です。
feature queryで分岐する
.container {
display: grid;
grid-template-columns: repeat(auto-fill, minmax(240px, 1fr));
gap: 24px;
}
@supports (grid-template-rows: masonry) {
.container {
grid-template-rows: masonry;
}
}
これだけで、対応ブラウザだけMasonry、非対応は通常Gridになります。
これだけで十分な理由
非対応環境では、等間隔Gridとして表示される。
崩れない。壊れない。最低限のUXは守れる。
派手さより安全性。これも実務の鉄則。
メリット 正直かなり強い
JavaScript不要
これは何度言ってもいい。
JSがない。つまり初期化がない。依存がない。
表示が速い
DOMロード後に再配置しない。最初から完成形で出る。
コードが読みやすい
CSSだけで完結するということは、引き継ぎが楽。
数年後の自分にも優しい。
デメリット 見ないふりはしない
対応ブラウザが限定的
これが最大の欠点。
今すぐ本番の主役にするのは難しい。
細かい制御ができない
高さの優先順位や配置順を厳密に制御したい場合は不向き。
ブラウザ任せ、という割り切りが必要。
仕様変更の可能性
新機能あるある。
将来的に仕様が変わる可能性はゼロではない。
ここでもう一度問いかけます。
それでもJSでMasonryを書き続けますか。
フロントエンド実務での個人的なスタンス
私はこう考えています。
今すぐ全置き換えはしない。だが、触らない理由もない。
小さなコンポーネント、限定環境、実験的UI。
そういう場所から積極的に使う。
CSSで完結する未来が見えているなら、今のうちから慣れておいた方がいい。
数年後、Native Masonryが当たり前になったとき、慌てないために。
関連して知っておくと強いCSSトピック
Container Queries
Masonryと組み合わせると、カード単位での最適化が可能。
Subgrid
カード内レイアウトと親Gridの整合性を取るのに便利。
Aspect-ratio
画像主体のMasonryでは必須級。
CSSは静的な言語ではなくなりました。
レイアウトはますますブラウザに任せる時代。
Native Masonryは、その象徴の一つです。
使うかどうかは状況次第。
ただ、知っているかどうかで、設計の選択肢は確実に変わります。
それだけでも、学ぶ価値は十分です。
