EVERY LAYOUTを読んだ

2021年11月29日

技術書は誰かに貸したり譲ったりすることがあるので、基本物理本で買うようにしている。とはいえ、Webに死ぬほど情報転がってるし、できるだけ物は買いたくないので最近はあまり買ってなかった。

自分はCSSが苦手な自覚があるので、最近の書き方はあまり積極的に勉強する気がなかったけど、知識をアップデートできるという噂を聞いたので買ってみた。

得たものはいろいろあるけど、一番の成果は自分が言語化できていなかったCSS設計に関する手法をしっかり言語化してくれていたこと。

そういう意味では真新しいものはそこまでなかった。

この記事は学んだことのメモ

要素のサイズは可能な限り、その内側のコンテンツと外側のコンテキストから「導出」されるべきということです。サイズを「規定」しようとするほど、問題が生じやすくなります。

めちゃくちゃ分かる。なんとなく無意識にそうやってスタイリングしてきたけど、ばっちり言語化されていて感動した。

コンポーネントの基本サイズはそのコンテンツのサイズによって規定されるべきで、コンポーネント自体にサイズを規定すべきではない。

また、コンポーネントはコンポーネントの外側のコンテキスト（コンテナや画面幅）の影響を受ける。そうやって全体のレイアウトを作っていく。そのロジックを書くのがCSSだと思う。

幅を基準としたメディアクエリの使用を避けています

その代わりにどうやってスタイリングしていくか。

• 幅によってフォントサイズを変えるならば、メディアクエリでパーツごとに変えるのではなく:rootのフォントサイズを変えることで全体のフォントサイズを調整する。
• SVGアイコンなど、フォントサイズが大きくなった時にアイコンのサイズも相対的に大きくしたい場合はemをつかう。
• chはそのフォントの「0」の幅（1chは「0」1文字分の幅）、exはそのフォントの「x」の高さを表す。
  • chは文字数で幅を決めたい時に使う。1カラムの幅は英字だと45〜75文字、日本語だと24〜40文字程度が良いとされている。
    • その幅をpxで指定してしまうと、フォントサイズが大きくなった場合にカラムサイズが変わってしまう。
  • もしchで幅を定義したボックスに水平パディングを追加したい場合はbox-sizing: contents-boxを指定することで、chのサイズを尊重することができる。

日本語だとchは使いづらいかも？とは思う。

.sidebar h2 という指定は、

特定のコンテキストにおける特定の要素の問題だけを解決するものです。一方で本来行うべきは、いかなるコンテキストのいかなる要素にも通ずる、より一般的な問題を解決することです。

この場合「.sidebarクラスの中にある」という特定のコンテキストに対するh2要素のスタイルを決めているが、本来はどんなコンテキストでも同じスタイルでうまくいくやり方を考えようってこと。いや、無理やろ。

こういう時に使うのが、TailwindのようなユーティリティCSSなのかなと思うけどどうなんだろうか。

IDセレクタ：詳細度の高さゆえに、全体に影響する問題をいくつも引き起こします。

自分はスタイリングのためにIDセレクタを使うことはないんだが、詳細度が高いと起きる問題ってなんだろうか。

コンポーネントのスタイルを当てたいけど、詳細度が高いスタイルが他にあって思うようにいかないとか？それは設計の問題で詳細度が高いことが問題ではない気がするけど。

propsを介した指定

カスタム要素のデフォルトのスタイルをJSのゲッターに書くのは抵抗がある。関心の分離とは。

公理は、目に見える成果物を直接的に作り出す物ではありません。成果物に現れる特徴を定めるだけです。

全くもってその通り。特徴というのはパターンとかだと思うんだけど、特徴が読み取りづらいデザインは設計しづらい。

Webのためにデザインすることは、目に見える成果物を作るのではなく、目に見える成果物を生成するための「計画」を記述する行為

なるほど、たしかにデザインは日本語に訳すと「設計」だけど、設計と計画はかなり似ているものがあるな…。

ブラウザをどのように動かすかを計画した結果、できるデザインがWebデザインか。

コツは、個々の要素ではなくコンテキストに対してスタイルを設定することです。

主語は「要素」ではなく「コンテキスト」。「.stack要素の子要素のうち2番目以降」というコンテキストにスタイルを適用するという考え方。

関係ない話

「デフォルト」という単語は、ブラウザの仕様の話をしているのか、本書のルールにおけるデフォルトの話をしているのか、あくまでサンプルコードにおけるデフォルトの値の話をしているのかがわかりづらいと感じた。

Every Layoutが解決するのは、堅牢で柔軟なレイアウトシステムであり、美観はその上に成り立つ。

すべてをEvery Layoutを解決しようとするわけではなく、まずはレイアウトシステムを作ったうえでその上に細部を作り込む。

多くの場合、グローバルスタイルの多くは「ブランディング」に関わるものである。

色やフォント、フォントサイズなどはグローバルスタイルとして定義されることが多いが、これらの要素はそのサイトの見た目の大枠を規定するものであり、それはブランドを強く示すものである。なるほど…。

感想。

できるだけマジックナンバー的な固定値をかかずに柔軟な、ある意味ブラウザにお任せしたレイアウトを実現する手法はとても好感が持てる。

また、レイアウトとブランドを切り離した考え方は自分がいつもやってきたスタイリングと近くて、なんとなくやってきたことが言語化された感じがしてよかった。

1つだけ気になったのは、Switcherのところで、コンテンツの数によってレイアウトが変わるスタイルの指定が紹介されていたけど、ちょっとここはやりすぎな感じがした。

どこかの章でも解説されていたけど、横並びが縦並びになることで、ユーザーが受け取る印象が違うみたいなことが描かれていた気がするけど、コンテンツの数によって印象が変わるのはどうなんだろうと思う。印象はコンテンツの中身によって変わるべきなのではないだろうか…。

あと、メディアクエリを禁止するあまりJavaScriptを使うのは、個人的には好きではない。JSでスタイルに介入するとしてもCSSのグローバル変数の値を書き換えるとかその程度にしておきたい。

以下EVERY LAYOUTを構成するものたちの雑多なメモ。

• ボックスモデル
  • inline：親の形に追従する
  • block：スタックできる箱
• コンポジション
  • 組み合わせ
• 単位
  • 相対的なサイズを意識する
  • 文字数を意識する
• グローバルスタイルとローカルスタイル
  • デフォルトのスタイル -> 例外的スタイルの順に適用した方がスタイルの全体量としては節約できるし分かりやすい（はず）
• モジュラースケール
  • リズムを生むスタイルを考える
• 公理
  • ルール、一貫性をデザインから読みとり、スタイルに反映する
• Stack
  • 縦に積んでいく（stack in stackもあり）
• Box
  • ボックス内部の考え方
• Center
  • 水平方向の中央寄せ特化
• Cluster
  • 要素を密集させる
  • gapとwrapをうまく使ったflexレイアウト
• Sidebar
  • 2カラムレイアウトで51%以上 + 49%以下のふたつがあるレイアウト
• Switcher
  • メディアクエリの代わりになるようなスタイルを持つ
• Cover
  • background-size: coverのような振る舞いをする
• Grid
  • そのまま
• Frame
  • Object-fitを使った縦横比レイアウトとクリップ
• Reel
  • 横スクロールするギャラリーのようなもの
• Imposter
  • ドキュメントに対して相対的に位置を固定する
  • ビューポートに対して相対的に位置を固定する
• Icon
  • そのまま。アイコンを示す