2015年、几帳面なやり方でCSSレイアウトを学ぶ

 (book.mixu.net)
6 ポイント 投稿者 GN⁺ 2024-03-01 | 1件のコメント | WhatsAppで共有
  • CSSレイアウトをすでに使ったことのある読者が、レイアウトアルゴリズムを細かな規則まで理解できるように作られた章立ての学習資料
  • inline、block、z-index、ボックスモデルを単なる使い方ではなく、フォーマッティングコンテキストやスタッキングコンテキストのような決定規則として説明し直している
  • 通常フローにおけるブロック要素とインライン要素の相対位置は display だけで決まるのではなく、兄弟要素やコンテキストもあわせて影響する
  • ボックスモデルのサイズや margin: auto の計算は、配置方式によって異なるため、ひとつの規則として暗記しにくい
  • 通常フロー、float、絶対配置、margin collapsing、overflow、z-index、疑似要素、Flexboxを経て、センタリングやグリッドフレームワークのような実践的レイアウト問題へとつながっていく

CSSレイアウトを規則として理解する

  • この資料はCSSレイアウトを小技集ではなく規則ベースのシステムとして捉え、各規則を章ごとに追いながら説明する長編の学習資料
  • 「pedantic」という表現のとおり、些細に見える細部や形式的な規則まで厳密に扱うアプローチを取っている
  • 対象読者はCSSを初めて学ぶ人ではなく、すでにCSSを使っているがレイアウトの動作をより厳密に理解したい人
  • Webサイトはたいてい段階的に発展していくため、小さなヒントやテクニックだけでレイアウトを身につけがちで、その過程でレイアウトアルゴリズムそのものを見落とすことがある
  • 主要な概念を順序立てて扱い、各概念を確認できる実例もあわせて提供している

章構成

  • Chapter 1: Box positioning in CSS は、HTML要素が作るボックスが互いにどのように配置されるかを扱う
    • CSSの3つの主要な配置方式: 通常フロー、float、絶対配置
    • 通常フローにおける anonymous box generation、formatting context、line box、line box 内での配置
    • float の順序、clearfix、float と親要素の高さの相互作用
  • Chapter 2: Box sizing in CSS は、ボックスモデルと配置方式による違いを扱う
    • height、width、margin の計算にはそれぞれ異なるメカニズムが使われる
    • 計算方法を理解するには、現在使っている配置方式と計算メカニズムをあわせて見る必要がある
  • Chapter 3: Additional properties that influence positioning は、ボックス配置に影響を与える追加のプロパティとメカニズムを整理する
    • margin collapsing、negative margins、overflow
    • max-width、max-height、min-width、min-height
    • stacking context と z-index
    • 疑似要素がレイアウトに与える影響
    • CSS3 box-sizing プロパティ
  • Chapter 4: Flexbox は、CSS 3 の Flexbox レイアウトモードを説明する
  • Chapter 5: CSS layout - tricks and layout techniques は、前章までの内容を実際の問題に適用する
    • 水平・垂直センタリング
    • CSSグリッドフレームワークの動作原理
    • 多段レイアウト
    • よくある落とし穴とレイアウトのテクニック
  • reference index は、特定の概念やプロパティを探して関連する章や節へ移動するときに使える

関連記事

1件のコメント

 
GN⁺ 2024-03-01
Hacker News のコメント

  • CSS レイアウトを説明するときに最初に言うべきなのは、互いに異なる4つのレイアウト体系があるということです。メールで今も使われている最も古い table、本文中の画像向けの float、現在最もよく使われる flexbox、そして table の現代的な代替である grid です。
    absolute と fixed の位置指定も、レイアウトを回避するハックのように使えます。

    • absolute と fixed はハックでもなければ、レイアウトを「回避」するものでもありません。
      どちらも、要素が文書フロー内、または特定のコンテナ内でどのように配置され動作するかを定める5つの位置指定オプションのうちの2つです: https://developer.mozilla.org/en-US/docs/Learn/CSS/CSS_layou...
    • 前の2つは、flexbox と grid 以前に使われていた代替のレイアウト体系に近いものです。
      float プロパティは Grid と併用することもできます。最も簡単で基本的なレイアウト体系である通常フローが抜けています: https://developer.mozilla.org/en-US/docs/Learn/CSS/CSS_layou...
    • 「table が最も古い CSS レイアウト体系で、メールでまだ使われている」というのは正確ではありません。
      実際の HTML table マークアップは、Web ページの一部を横に並べて配置する最も古い方法の一つで、メールでも使われていますが、それは CSS とは別の話です。
      CSS には display: table と関連する値がありますが、記憶では昔の IE では float より使いにくく、利用も限定的でした。現代の Web でも広く使われているのをほとんど見たことがなく、周辺のマークアップ要件が厳しすぎるせいかもしれません。たとえば順序を変える方法がなく、複数行が必要なら HTML の中にその役割を担う要素を入れなければなりません。
    • 付け加えると、Flexbox Froggy は flex を学ぶ最良の方法で、CSS を書く前に他の人が作った css-reset ルールを取り入れるのがよいです。
      古い後方互換の挙動を、合理的なデフォルトに変えてくれるからです。例: https://www.joshwcomeau.com/css/custom-css-reset/#our-finish...
    • table は最も古い CSS レイアウト体系ではありません。それはフローレイアウトであり、奇妙なことにこの一覧からは完全に抜けています。

  • float が「コンテナボックスの左端と右端にボックスを配置するために使われる」という説明は正確ではありません。
    float でそうすることはできますが、flexbox と grid が登場してからはそのようには使いません。要素が通常フローから外れるため、CSS を学ぶ人にとってはレイアウトを作るうえで混乱を招く方法です。
    float はレイアウトツールというより組版ツールに近いものです。本文が自ら pedantic だと言うなら、もっと綿密であるべきです。

    • HTML/CSS 入門では、これらの技術が最初に作られたとき、オンライン文書のレンダリングだけを目的としていたという事実を必ず説明すべきです。
      基本的には、他人のコンピュータ上にあるファイルのための Microsoft Word のようなものとして作られたので、float のような初期のプロパティの大半は組版レイアウト向けでした。
    • コンテナ内のすべての要素は、コンテナの上側へ、そしてテキスト方向が ltr か rtl かに応じて前の要素の右側または左側へ浮き上がります。
      残りのスペースがなければ、前の要素たちの下へ降ります。要素が display: block なら横方向のスペースをすべて埋めるので、その後のすべての要素はその下へ浮き上がります。だから名前が float であり、要素位置を計算する方式です。
      float:left|right を使うと、同じコンテナ内の他の要素より先に、その要素を左または右へ強制的に浮かせます。もちろんコンテナが flex や grid を使っていれば、もはやこのようには動作しません。
    • 第1章の大きな部分（https://book.mixu.net/css/1-positioning.html#float-positioni...）が float の複雑さと特殊なフローを扱い、その挙動を別の目的に慎重に再利用・応用する方法を説明しています。
      特に執筆当時には flexbox/grid レイアウトがなかったことを考えれば、十分に綿密な説明だと思います。
    • flexbox レイアウトでは、このツールがプロセスを単純化してくれます。
      複数のプロパティを気にする必要を減らしてくれます: https://flexboxcss.com
    • float を使わずに sidenote や marginal note をどう配置するのか、よく分かりません。
      特にノートを段落中の参照位置に合わせて揃える必要がある場合はなおさらです。

  • こういう記事は CSS Grid 以前の記事であっても、気が重く感じられる。CSS Grid が登場してから、CSS レイアウトはさらに複雑になり、Web 開発を10年やっていても CSS はいまだに底が見えない気がする。
    動作の仕組み、珍しい例外ケース、内部挙動、膨大な機能数がそうだし、最近その件についての記事も書いた。
    Grid Layouting の細部を追いきる前に、subgrid と container queries が出てきた。新しく追加された多くのプロパティは、あまりに特定のケースを扱うものなので、使う機会があるのか疑わしい（hanging-punctuation、font-palette など）。
    段落のハイフネーション関連のプロパティだけでも少なくとも3つあり、filter プロパティが SVG を使うまったく別種のフィルターもサポートしていることを知らないかもしれない。画像のスケーリングアルゴリズムを調整することもできるし、border-radius は楕円形の角もサポートしている。
    どんな技術についてもこういうことは言えるが、CSS は違う。あまりに多くのことを、あまりに多くの方法で扱い、あまりに多く、あまりに速く変わる: https://shubhamjain.co/2024/02/19/css-impossible-thats-okay/

    • 「Web 開発を10年やっていても CSS はいまだに底が見えない」というのがどういう意味なのか気になる。
      もっと長く CSS を扱ってきたが、align-items なのか justify-content なのかを覚えようともしていないので思い出せない。flexbox を使うとなった瞬間に https://css-tricks.com/snippets/css/a-guide-to-flexbox/ を開く。
      Grid はさらに覚えていない。それでも何度かぶつぶつ言って WTF となっていれば、欲しいものは十分簡単に作れるので、底が見えないという感じはしない。CSS についてこういう話はよく聞くが、ほとんどの場合、大した努力なしに望むレイアウトを作るのはかなり簡単だと感じる。ただ JS のように CSS を記憶していないだけだ。
    • CSS レイアウトに関心があるなら、まず Flexbox と CSS Grid を学ぶことを勧める。
      どちらもドキュメントがよく整っていて比較的直感的で、特に grid は変わった挙動が少ない。
      最近はフローレイアウトを深く知らなくてもよく、float と table レイアウトは完全に飛ばしてもいい。本来の用途だった、テキストコンテンツ内の浮動画像と実際の表にだけ使えばよい。
    • フロントエンド作業でいつも直面する問題は、あらゆる記事が、この15年間ずっと最新の流れを追い続けてきた人を読者として想定していることだ。
      初めて実際のフロントエンド仕事をしてドルを受け取ったときは、perl から直接 DHTML を生成していた。その略語を打つことすら筋肉記憶のキャッシュからあまりに遠くへ消えてしまい、指がもたつくほどだ。
      フロントエンドについては、6歳児が微積分を知っている程度にしか分かっていないので、もう追いつく方法がないように感じる。
    • 自分も似たようなものだ。単に grid をあちこちで使い始めれば、たいていうまく動く。
      ただし plain CSS を使っていて、グローバルなスタイルシートも普通は置かないので、かなり助かっている。
    • もっと悪いこともあり得る。LaTeX かもしれないのだから。

  • UI アプリを多く開発していて、主に Angular を使っているが、最近は単に Bootstrap や Foundation のようなフレームワークを使っている。
    純粋な CSS の膨大なレイアウトオプションは、特にレスポンシブデザインでは圧倒的で頭が痛い。純粋な CSS を試したこともあるが、結局多くのボイラープレートを使い、ミニフレームワークのようなものを作ることになる。
    カスタムデザインの Web サイトを作っているのでなければ、車輪の再発明を続ける必要は個人的には感じない。

    • ボイラープレートはまだ多少あるが、Open Props はハイブリッドなアプローチなので気に入っている。
      CSS が必ずしも車輪の再発明というわけではなく、難しいレイアウトや、もともと JS が必要だった作業を、より簡単で強力にできるようにしてくれる。
      Bootstrap も悪くないが、高度なレイアウト問題を解決しようとすると、実際にどんなスタイルが適用されているのかを見るために要素の検査をたくさんすることになる。少なくとも自分の経験ではそうだったので、個人的には CSS 側に賭ける。
      期待している新機能は @scope ルールで、スコープ付きスタイルをずっと簡単に作れるようにしてくれそうだ。
      https://open-props.style/
      https://developer.mozilla.org/en-US/docs/Web/CSS/@scope
    • flexbox、grid、media query のような新しい CSS 機能は、Bootstrap のようなフレームワークの必要性を減らすために追加されたものだ。

  • この記事は CSS Grid と CSS columns 以前に書かれたものなのか？
    z-index に関する記事もある: https://philipwalton.com/articles/what-no-one-told-you-about...

    • その通り。https://book.mixu.net/ によれば2015年に書かれたもので、9年前の記事なら現代の CSS にはあまり役に立たないのではないかと心配になる。

  • 第3章で margin collapsing と negative margins を扱っているのを見ると、この記事は古いレイアウト手法の理解を優先している。
    レガシーなコードベースを扱うときには価値があるが、新規プロジェクトでは避けたほうがよい。

  • CSSを深く学ぶ最良の方法は何だろうか？ 公式ドキュメントは、何が現在有効で何がそうでないのかが少し奇妙に感じられる

    • “actual”を“current”の意味で使うのは本題から外れるが、自分の好きなEU英語的表現の一つ
      オランダ語では current が actueel、actual が daadwerkelijk と訳されることを考えると、十分理解できる。ネイティブが混乱するなら、むしろ助けになるかもしれない
    • 最良の方法は、繰り返し何かを作ってみることだと思う
      特定の学習スタイルに合った話かもしれないが、実際にスタイルやレイアウトをいじってみると、動作の実用的な側面が確実に身につく
      CSSを書くときは、できるだけ少なく書くことを目標にしている。CSSが嫌いだからではなく、むしろ不当に悪い評判を受けていると思っているが、宣言を過度に重ねずにレイアウトをより効果的にスタイリングする方法を学べるからだ
    • 今週、フロントエンド技術を学び直しながら、市場調査を少ししてみた
      CSSの基礎に最も良かった資料は https://web.dev/learn/css で、flexboxとgridも含まれている
      デザインガイドラインとしては Refactoring UI を薦める。The UX Book のような本に足りない、実行可能なアドバイスが多い
      自分のプロジェクトでは、Refactoring UI の著者による TailwindCSS と Daisy UI コンポーネントを使っていて、実際には raw CSS は書かない。最初は TailwindCSS が inline CSS への退化のように感じられるが、代替手段より単純に良い。一度使ってみることを薦める
    • ここでいう「公式ドキュメント」が何を指しているのか気になる。仕様書[1]なのか、MDN[2]なのか？
      [1] https://drafts.csswg.org/
      [2] https://developer.mozilla.org/en-US/docs/Web/CSS
      前者は新しいWeb開発者向けの学習資料ではない。後者も公式または権威ある文書ではないが、通常はBaselineサポートとブラウザ互換性表に関する情報がある
    • flexboxを学び、ボックスモデルを学び、特に margin と padding をいつ使うかを身につけるとよい
      スタイルのカスケード適用がどう動作するかも学ぶとよく、それによって SCSS やコンポーネント開発を使って、その大半を気にしなくて済むようにする理由も理解できる
      media query と画面サイズ別のターゲティングも身につければよい。何より「CSSで x をする方法」をWeb検索することを恥ずかしがる必要はない。仕様は巨大で覚えることが多く、長い間頻繁に使っていなければすべてを覚えてはいられない