CSS Grid Level 3「Masonry」レイアウト標準化に向けたWebKitのフィードバック募集

 (webkit.org)
2 ポイント 投稿者 GN⁺ 2024-04-24 | 1件のコメント | WhatsAppで共有
  • WebKitは、CSSで長らく扱いが難しかった masonry/waterfall レイアウト を CSS Grid Level 3 として標準化するにあたり、デザイナーと開発者からのフィードバックを求めている
  • 提案されているモデルは、display: grid の上で grid-template-rows: masonry により 行の生成を無効化 し、コンテンツをレンガのように空きスペースへ詰めていく方式
  • Appleは、この機能が Grid の中にあることで、fr、minmax()、max-content、spanning、明示的配置、subgrid といった既存の Grid 機能と組み合わせられると考えている
  • 別個の display: masonry 方式ではレイアウト種別を単純に分離できる一方、議論の流れでは 同一幅カラム 中心に制限される可能性があり、Grid のトラックサイズ調整能力を活かしにくい
  • 2024年10月の更新以降、CSS Working Group は可変幅トラック、明示的配置、spanning、subgrid を masonry に含める価値があり、性能面でも実装可能だと結論づけたが、構文の議論は継続中

CSS Grid Level 3の現在地

  • 2024年10月の更新後、CSS Grid Layout Module Level 3 の正式な W3C Working Draft が作成され、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 によりコンテンツを追加しても既存コンテンツを動かさずに済む

提案の歴史と標準化をめぐる議論

  • CSS で masonry レイアウトを作る仕組みは、Mozilla が 2020 年 1 月に CSS Grid の拡張 として初めて提案し、Firefox Nightly でフラグ付きの実験機能として実装された
  • Apple は 2022 年に Safari Technology Preview で CSS Grid Level 3 の提案実装を開始し、現在はデフォルトで有効になっている
  • CSS Working Group 内では基本方針をめぐって意見の違いがあった
    • masonry は CSS Grid の一部ではなく、独立した display タイプであるべきだとする意見
    • そもそもこのレイアウトが Web に本当に必要なのか、有名サイトが使うのか確信が持てないという意見
  • WebKit は、ブラウザがこの機能を出荷するには、まず CSS Working Group の合意 が必要だと見ている

基本的な使い方: 行を無効にしてカラムだけ使う Grid

  • 古典的な masonry/waterfall レイアウトは、main 要素に display: grid を適用してカラムを定義し、行方向に 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 パターンで詰めるよう指示する
  • この例は、メディアクエリやコンテナクエリなしに 4 行の CSS でさまざまな画面サイズに対応する柔軟なレイアウトを作る
  • 現在の masonry という値名は、ブラウザ出荷前に変更される可能性がある

Grid のカラム定義能力を維持したい理由

  • WebKit は、masonry が CSS Grid の一部であるべき理由を示すために 4 つのデモを作成しており、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 は、カラムサイズをコンテンツサイズに合わせることで、コンテンツをカラムに合わせるのとは異なる配置を可能にする
  • grid-template-columns: 1fr 1fr 2fr 3fr 5fr 8fr; のように Fibonacci sequence を使って異なる幅のカラムを作ることもできる
  • 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 枚ごとの画像を 2 カラムにまたがらせ、それ以外の画像は 1 カラムだけ占有させられる
  • 横長のアスペクト比を持つ画像に wider クラスを与えて複数カラムにまたがらせたり、角を四角くしたり、間隔を 0 に縮める変形もできる
  • Photos デモは View Transitions と組み合わせられており、ユーザーが写真をクリックまたはタップすると、その写真が複数カラムにまたがって拡大し、ブラウザが遷移を自動アニメーションする
    • このデモには Safari Technology Preview 192 以上が必要
  • WebKit は Grid Level 3 の本質を、「masonry」という特定パターンよりも 行を無効化するメカニズム にあると見ている
  • この方式はカラムだけで構成される columnar grid を生み、CSS Grid Level 1 が得意とする、行と列の両方が揃った modular grid と対比される

Modular grid と columnar grid の違い

  • modular grid は、コンテンツがカラムと行の両方に揃えられる Grid であり、CSS Grid Level 1 はこの種の配置に適している
  • float ベースのレイアウトでも、float を正しく整列させるためにはコンテンツの高さを揃える必要があり、そのことが Web における modular grid の利用を後押ししてきた
  • 実際の Web サイトでは、画像のアスペクト比を揃えたり、テキストの長さを合わせたり、CMS の方針や CSS の切り抜き・省略表示によってコンテンツを同じ箱に収めることが多い
  • columnar grid では、コンテンツに本来のサイズを保たせたまま、レイアウト側がコンテンツに合わせて動作できる
  • WebKit は、最新記事を 4 カラム分にまたがらせ、最近の記事の一部を 2 カラム、古いコンテンツを 1 カラムに配置する例を通じて、テキスト中心のコンテンツでもより生き生きとした配置が可能だとしている

Subgrid と明示的配置の組み合わせ

  • CSS Grid Level 2 の subgrid は、ほとんどのブラウザでサポートされている
  • 博物館ページの例では、絵画カードのメタデータを 1 本の左揃えカラムに並べる代わりに、subgrid を使って年号とカタログ番号を各カードの右側に配置し、他カードの同種データと行を揃えている
  • masonry が CSS Grid Level 3 に入れば、既存の開発者ツールもそのまま活用できる
    • Safari Technology Preview の Grid Inspector で grid-template-rows: masonry を試せる
  • 独立した display タイプになると、subgrid の利点 は得られない
  • CSS Grid Level 1 の明示的配置も併用でき、例では grid-column: -3 / -1 によってヘッダーを最後の 2 カラムのページ右上に配置している
  • WebKit は、数行のレイアウトコードで Grid Level 1、2、3 の機能を組み合わせ、メディアクエリやコンテナクエリなしに利用可能サイズに応じてカラム数が変わるレイアウトを作れると見ている

display: masonry をめぐる論点

  • WebKit と Apple は、Masonry を CSS Grid の拡張として、modular grid だけでなく columnar grid も作れるようにする機能だと考えている
  • この方向では、カラム定義、track spanning、明示的配置、subgrid などの Grid 機能を一緒に使える
  • 独立した display タイプを支持する側は、レイアウト種別をきれいに分離できると考えている
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 */
}
  • 独立したレイアウトタイプにすると、Grid と Masonry を継続的に連携させるための作業を避けられる
    • レイアウトモデルが単純になる
    • ブラウザ実装が容易になる
    • 性能上の落とし穴の可能性が減る
    • Grid と Masonry の機能セットを異なるものにできる
  • 一方で WebKit は、2 種類の Grid レイアウトがつながっていれば、CSS Working Group が将来の機能を modular grid と columnar grid の両方について定義するようになると見ている
  • たとえば CSS Grid Level 4 で grid area や grid line のスタイリング、トラック背景色、gap の rule line などの機能が追加されるなら、最初から両方の Grid タイプで動く方がよいと考えている

「Grid」をどう捉えるか

  • 独立した display: masonry を支持する側には、CSS Grid は本質的に 2 次元整列であり、masonry は一方向だけの整列なので Grid ではないと見る人もいる
  • WebKit は、グラフィックデザインの歴史において grid は、テキスト・画像・コンテンツを規則的パターンに整列させ、可読性と使いやすさを高めるための道具だったと捉えている
  • 20 世紀の欧州や米国のモダニストが、カラムと行の両方を揃えることを「proper」なグラフィックデザインの grid として強調する以前から、多様な grid は使われていた
  • Mark Boulton は、対称的な columnar grid は形式的で退屈だとし、Web デザインでは非対称な compound grid の利用を促した
  • CSS Grid Level 1 は非対称 grid や compound grid を簡単に作れるようにしたが、現状ではその Grid が modular grid の場合に限られる
  • WebKit は、modular grid も columnar grid もどちらも grid であり、CSS Grid も columnar grid を作る能力を持つべきだと考えている

開発者とデザイナーへのフィードバック募集

  • WebKit は、開発者とデザイナーに対し、実際にデモを作り、ブログやソーシャルメディアで意見を書き、CSS Working Group の issue にコメントしてほしいと呼びかけている
  • フィードバックを求める問いは次のとおり
    • 「masonry」/「waterfall」は CSS Grid の一部であるべきか
    • subgrid、spanning、明示的配置、多様な track sizing を含む columnar grid 機能は必要か
    • 同一サイズカラムの古典的 masonry レイアウトだけで十分か
    • 実際にこの機能を使うか、何を作れそうか
    • 作成したデモへのリンクはあるか
    • このモデルではできないことがあるか
  • WebKit チームは Masonry の作業を 1 年半にわたって進めており、2023 年 2 月の Safari Technology Preview 163 でデフォルト有効化された
  • 早期に機能を出荷したいが、名前を含む細部や根本的な問いが先に解決される必要がある

名前の議論: masonry, waterfall, off

  • WebKit は、masonry が新しい値の最適な名前ではない可能性が高いと見ている
  • CSS の名前は通常、center、contain、clip、wrap、smooth のように、結果を直接表す単純な語であることが多い
  • masonry は背景説明が必要な比喩であり、英語を使わない開発者には覚えにくい可能性がある
  • 地域によってはこのレイアウトを waterfall と呼ぶ方が一般的なため、grid-template-rows: waterfall も候補になりうる
  • WebKit は、この機能が Pinterest 的なレイアウトそのものよりも、「Grid を作るが行は作らない」というメカニズムに近いと考えている
  • 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 とデモでは Editor’s Draft に合わせて masonry 値が使われているが、将来的に名前が変わる可能性がある

関連記事

1件のコメント

 
GN⁺ 2024-04-24
Hacker News の意見

  • 背景としては、ブラウザベンダーの CSSWG 開発者リレーション担当者たちが、Masonry レイアウトを CSS に正式に取り込む方法を議論してきたということです。少なくとも Firefox が最初に提案した 2020 年から続いている議論です
    今回のニュースのポイントは、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 仕様にかなりうまく収まります。強力な列定義プロパティとサブグリッドを再利用できるためで、例もこれらの機能が互いにどれほど直交しているかを説得力を持って示しています
      概ね grid-row-template: masonry だけを使えば、残りはそのままうまく動作します。この点は良いことで、Grid レイアウトを今より使いにくくするものではないと思います
      欠点は主にブラウザエンジンの作者側にあります。「CSS Grid 完全対応」の基準がより高くなるためです。また、Grid のすべての機能をサポートしなければならない実装は、仕様がもっと単純だった場合よりも一部の Grid レイアウトで遅くなり得る 性能の罠も避けられるといいます
      別の display モードがあるなら、Masonry レイアウトのために grid-column 仕様を繰り返す必要があり、それは残念です
    • こうしたことがコミュニティのフィードバックに委ねられたのは初めてではありません。ネストされた CSS セレクタのときも同じ方式で進められ、フィードバック面ではかなりうまく機能しました: https://webkit.org/blog/13607/help-choose-from-options-for-c...
    • 妥協点を探っていると、最初の好みを考え直すことになる場合があります
      CSS Masonry と直接関係はありませんが、最近、似たような緊張関係のあるインターフェースの 2 回目の反復をプロトタイピングしました。データモデルで似ているが異なる型を増やすのか、既存の型の中に細かなニュアンスを増やして洗練を支えるのかという問題でした
      始めたときは後者を強く支持していましたが、実際に選択肢を探ってみると、むしろ「膨らんだ」インターフェースを利用し、その結果としてアプリケーションコードを推論するほうがずっと単純でした
      CSS Masonry について強い立場はありませんが、人々が直感的に考える緊張関係と、実際に使ったときの感覚との間に、同じような驚きがあるかもしれません。CSS では特に「肥大化」、つまりユースケースごとの意味の増加を正当化するのは難しいでしょうが、ユーザーは Grid のような 密度の高い API をより難しく感じる傾向もあるかもしれません
    • このように公開で進めるのは良いことです。昨年から関係者全員にずっと働きかけていました。Chrome 側が最も遅れており、まだサポートがありません。Firefox にはフラグ付きのサポートがあります
      昨年から Firefox と Safari でテストしてきましたが、実装に不満はありません。プロパティの位置や名前について不平を言う人もいますが、完璧な解はおそらくないことを認め、実用的に実装すべきです
      代替実装に JavaScript を使うのは拒否します。そのため代替方式には順序を正しく合わせられない見苦しい 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....。正しい読み順とタブインデックスに影響します。視覚ユーザーは実質的に常に「間違った」順序で読むことになります
    結局、構造がなくリンクが入った非構造的な袋にすぎないことを示しています。ところが番号順に追ってみると、かなり論理的な順序があったように見え、不適切に Masonry 化したせいで完全に台無しになっています
    スクリーンショットでは「項目番号を表示」をオンにしています。通常は背景のない普通の列のように見えます
    実装は列を使い、各セクションに break-inside: avoid を追加すべきでした。デモではこれが抜けています
    新聞デモも似た理由で少し疑わしいですが、問題はずっと小さいです
    画像のようなメディアなど、より独立したブロックで、読み順がそこまで深く組み込まれていない場合には、Masonry レイアウトのほうが合います。それでもタブインデックス周りには少し曖昧な部分がありますが、もはや明白に間違っているわけではありません

    • アクセシビリティツリーとタブ順が実際のコンテンツ順を迂回し、列を一つずつたどるという意味なら、それはバグだと思います
      Masonry レイアウトで視覚ユーザーが期待するのは、列の間に連続性があることではなく、視覚的な行に沿って続くことです。「予想外」として示した順序もそれに従っています
      問題は、タブ順が元のコンテンツ順を無視して視覚的なものを真似ようとしている点にあるように見え、ほぼ確実に現在の実装方式の名残でしょう
    • 視覚ユーザーだけで見ると、現在の順序は妥当に見えます。提案された方式では、項目を順番に見ようとすると頻繁に上下へスクロールする必要があり、項目がさらに追加されると大きなレイアウトシフトが起きる可能性があります
    • Masonry 効果なら、広くサポートされている CSS マルチカラムレイアウトを使えばよいのでは？
    • 単なる任意のデモにすぎず、フィードバックを集めようという概念そのものとはあまり関係がなさそうです

  • この機能の良い点は、対応していないブラウザ、つまり特別なフラグを有効にしていない現在のすべての安定版ブラウザでデモを見ても、Grid レイアウトの上に直接作られているため、かなり合理的な固定行形式で表示されることです: https://webkit.org/demos/grid3/
    いずれの場合も、きちんとした Masonry レイアウトならずっと見栄えがよくなりますが、そうでなくても十分に使えます。気に入らなければ機能検出を使って、より良い代替表示を提供することもできます

  • Masonry／ウォーターフォール型レイアウトの全体的な見た目と感触は本当に良いです。紙の新聞を読んで育ち、今も読んでいるからか、列ベースのレイアウトはページを分ける直感的な方法のように感じます
    ただし、デフォルトの Masonry 配置に代わるものがあるとよいと思います。知る限り、基本ルールは「次の項目を最も上に入れられる列に配置する」というもので、そのため2行目以降は左右の順序が大きく入り乱れます
    想像しているより良い方式は、左→右、または優先方向が右→左ならその読みの流れをより保つレイアウトです。たとえば「次の項目は前の項目の右の列に入れる。ただしすでに最も右なら最も左に入れ、新しい下端が左の列の下端より大きく下がりすぎない場合は、同じ列に2つ目の項目を入れてもよい」といった方式です
    厳密な左→右より柔軟なので、配置もそれほど崩さず、左→右の読み方向の意味もある程度保てます
    Masonry で好まれ得るあらゆる公式を受け入れることはできないでしょうが、順序が少しでも重要なコンテンツなら、Pinterest ではないにせよ、ジャーナルのような場合には、この方式のほうが古典的な Masonry ルールより合理的なデフォルトだと思います

    • 明確な順序がそもそもないものにだけ Masonry レイアウトを使うと思います。時系列で並んだ画像には使わないでしょう
    • 問題は左→右の配置そのものです。このレイアウトであちこち飛ばずに左→右に並べる方法はほとんどないと思います
      雑誌風レイアウトなら、列を上→下に先に読み、その次に左→右に読むのでは？ CSS ではすでに columns や縦方向の Flexbox で可能です
      この Masonry レイアウトのもう一つの問題は、下端が不ぞろいになることです。雑誌ならおそらく均等にそろえたはずで、これも列や Flexbox でできます
      Web では、無限にスクロールされるコンテンツという隠れた前提があり、ページ下部の見た目は重要ではないと見なしているようです。だとすれば、必ずしも推奨すべき前提ではありません
    • こんな形ではどうでしょう:
      { /* 更新時に要素を左または右へ最大2列だけ移動 */ grid-template-max-horizontal-shift: 2 col; }

  • CSSを置き換える下位互換性のないシステムを作れるとしたら、どうすべきだろうか？
    一貫したレイアウトシステムの作り方についての本や論文はあるだろうか？
    Qt、Tk、SwiftUIのような代替案はどうだろう？ CSS以外は使ったことがない。実際に広く実装されているシステムでもっと優れたものがあるなら、何が理由で優れているのだろう？
    開発者により良いインターフェースを提供するシステムが欲しいが、どうすればいいのか分からない。最初からやり直せるなら、設計原則は何であるべきだろうか？

    • 特に反CSSというわけではないが、サイズグループ、予測可能なサイズ要求・割り当てサイクル、高さに応じた幅、制約および整列ベースのレイアウトといった概念には関心を持つ価値がありそうだ。そして、CSSで直交せず絡み合っている概念の混乱を全体的に整理する必要がある
      プロパティはもっと明示的で分離されているべきだ。負のマージンのような悪手はなくし、すべての距離は多段階にすべきだ。たとえば padding = max(el.paddings[]) のような形だ
      境界ボックスは明示的にし、ボーダーはきちんとした要素にすべきだ。ボックスモデル自体が悪いわけではなく、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ライブラリを検討したが、結果には満足できなかった
    実際に利用可能なすべての空間を埋めるまともなMasonryレイアウトは、一部の画像をトリミングする。トリミングせずアスペクト比を維持するには、写真の周囲に余白を残す必要がある。それをしない唯一の方法は無限スクロールだが、企業型の依存形成マシンが望むのはそれだとしても、私のWebサイトで望むものではない
    こう作った:
    https://yakubin.com/photography/albumless/
    https://yakubin.com/photography/album/kenya-2023/
    この結果を得るために display:inline-block を使い、写真を新しい行へリフローされるべきテキストのように扱ったわけだ。結果にはとても満足しており、Masonryライブラリのやり方より好んでいる

    • このレイアウトは、折り返して中央揃えする行方向Flexboxで、CSS数行ならおそらく実装できたはずだ。そちらのほうが標準的な方法でもある
    • MasonryレイアウトにJavaScriptは使わない。現在のMasonry CSS解法でサポートされるCSS解法を代替表示として置いている
      問題は順序だ。順序が重要でないなら、現状のCSSだけの解法でもうまく動く。ただ記憶では、列の下部に奇妙な形が残ることがある
    • こうしたレイアウトはFlexboxが設計された用途なので、ここでも選択肢になり得る

  • 関連して、Gridの原理を扱うインタラクティブデモを作った:
    https://cssprinciples.com/3/grid/

  • 既存の float があり、モダンな Flexbox と Grid レイアウトもあるのに、CSS に「レイアウト」オプションを追加し続けるのが正しいのか疑問に思う
    まだカバーされていないケースがあるなら、複雑になっても、あらゆるレイアウト事例をカバーする最後の 制約ベースのシステム を1つ用意するほうが、より良い解決策かもしれない。そうすれば CSS フレームワークやユーティリティライブラリが、その上に次世代の Masonry Grid などを作れる

    • 制約システムが実際に検討されるかは懐疑的。CSS はこれまで、レイアウトコストの予測可能性を強く目指してきた
      それでも Houdini レイアウト提案が、この考えに最も近い。レイアウトを隔離された JavaScript コンテキストに渡す方式: https://github.com/w3c/css-houdini-drafts/blob/main/css-layo...
      ただ正直、Flexbox と Grid、そして containment のようなものがすでに多くの問題を解決しているので、Flexbox 以前の時代より改善要求はずっと少なくなっている
    • この動きの核心は、古い float ハックや、近いうちに古びる CSS Grid/Flexbox ハックを使うのをやめようということ。Firefox の Masonry レイアウトは、実際には Grid の行を折りたたむ新しいプロパティを1つ追加する方式なので、事実上あらゆるレイアウト事例をカバーする形で実装されている
    • これは Grid レベル 3。こう書ける:
      display: grid;
      grid-template-rows: masonry;
      ただし WebKit に限られる。個人ニュースフィードのギャラリーモードに実装したが、すでに2023年10月に捨てた
    • JavaScript が最終的なレイアウトシステム。どんな宣言型言語でも、すべてのユースケースを処理することはできない。幸い Grid が出てからは、JavaScript に依存することはまれになった
      制約ベースのシステムは Grid と JavaScript の中間のどこかにぎこちなく位置しそうで、大きな助けになるかは分からない
    • CSS レイアウトが直接サポートしない要件があるなら、いつでも JavaScript でレイアウト を生成できる

  • すでにこれを使っている。Firefox ではオプションで有効にして、ブックマークに活用している。モバイルでは単に上下に積み重なるので問題にならない。モバイルには about:config がない
    最後の画像はオフにした状態
    https://imgur.com/a/o7OyZEW

    • 私の理解では、Masonry レイアウトのルールは最も高い空きスペースを行単位で先に埋めるため、不規則な整列が生じる。ただし視覚的には列に揃っているように見える
      そのため、ウィンドウサイズを変えると ブックマークの順序 が変わるはず
    • モバイルでは Firefox ベータを試してみて :)

  • より多くの背景と反対側の主張、つまり display:grid + grid-template-rows: masonry より display: masonry のほうがよいという議論は、ここで詳しく見られる: https://github.com/w3c/csswg-drafts/issues/9041