「CSS 設計完全ガイド」を読んだ

投稿時刻2023年10月18日 15:34

「CSS 設計完全ガイド」を 2,023 年 10 月 16 日に読んだ。

目次

メモ

1-1 CSSの始まり p12

CSSはとても貧弱です。
これはCSSの文法がシンプルで、少し学べば誰でも扱えるようになる、群を抜いた簡単さの弊害でもあります。

CSSの歴史は意外に古く、1994年に提唱され、1996年12月にCSS1としてW3Cにより勧告されました。
その後CSS1の上位互換として1998年5月にCSS2が、CSS2の改訂版として少し期間が空いて2011年6月にCSS2.1が勧告されました(図1-1)。
※ 国際的な標準仕様として承認されることです。

CSS3からは画一的なバージョンというわけではなく、アニメーションに関する仕様や、
グラデーションに関する仕様などを「モジュール」という単位とし、モジュール単位で定義されるようになりました。
そのため、「CSS3」「CSS4」といったCSS全体を指すバージョンは厳密には存在しません。

日本で使用され始めたのはおおよそ2002年頃からで、それから今日にいたるまで業界標準として使用され続けています。

p19

2011年頃に Nicolle Sullivan 氏がOOCSSを提唱し始めたのをきっかけに、
その後 BEM や SMACSS 、SUIT CSS 、 MCSS 、 Systematic CSS などのCSS設計手法が世界各国で開発され、広く使用されるようになりました。
日本においてもCSS設計は開発されており、谷拓樹氏による FLOCSS 、筆者による PRECSS などがあります。

これほど多くの CSS 設計手法がありますが、「ではどれが一番いいのか？」という問いには残念ながら明確に答えることはできません。
なぜならWeb開発には小規模なものから大規模なもの、単なるコーポレートサイトからECサイト、Webアプリケーションまであり、
CSS設計においても規模や開発するWebサイトの性質によって、それぞれ最適なものが異なってくるからです。

しかしどのCSS設計にも共通して言えることは
抽象化する
分ける
でしょう。

抽象化と聞くとイメージが湧きづらいかもしれませんが、
大まかに「異なるスタイル間で共通するものは何か？」「共通する部分を切り出してひとつにまとめられないか？」を考える作業と思ってください。

「分ける」に関しては、大きく
ファイルを分ける
パーツの大きさで分ける
役割に応じて名前を分ける
の3つの手法に分類できます。

それぞれのCSS設計がどのレベルまでこれらを行っているのかを見比べるのはとても面白く、また学びも多いものです。
実際に採用しないにしても、一度複数のCSS設計にも目を通してみるといいでしょう。

本書においては、 Chapter 3 「さまざまな設計手法」にて
OOCSS
SMACSS
BEM
PRECSS
の紹介を、また Chapter 5 ~ 7 の「CSS設計モジュール集」において、BEMとPRECSSを用いて実際に Web パーツ (以下、モジュールと呼称します) を作成していきます。

CSS設計とデザインシステムとの連携 p21

「抽象化する」「分ける」という方向でCSSに秩序と平和をもたらそうと試みたCSS設計ですが、これには思わぬ利点がありました。
Webの肥大化・複雑化に伴い増加し続けるページ数、モジュール数に頭を悩ませていたのはデザイナーも同じだったためです。

そんな中、「Atomic Design (アトミックデザイン) 」という方法論が Brad Frost 氏によって提唱されました。
Atomic Design は端的に言えばデザインシステムを構築し、運用するための考え方、及び指針です。

本書の範疇から逸脱してしてまうためすべての解説は省きますが、
Atomic Design では 「Atomic Design Methodology」という方法論の中で UI (User Interface) を 
Atoms
Molecules
Organisms
Templates
Pages
の5つに分離して再整理 (用語がとても化学的ですね) している点に、CSS設計との共通点を見いだせます。
図 1-5 は Atomic Design Methodology のUI分類に関する全体概要図です。
http://atomicdesign.bradfrost.com/

Atomic Design Methodology 自体はCSS設計を念頭においたものではなく、あくまでデザインシステムを構築するための方法論です。
しかし現実に Atomic Design によって定義されているUIの5つの分類はCSS設計とも少なからず親和性があり、特にPRECSSの理解には役立ちます。
UIの5つの分類について少し詳しく解説したコラムを用意しましたので、ぜひ参考にしてみてください。

Atomic Design Methodology における UI 分類の考え方 p22

デザインシステムの観点からUIの再整理を行った Atomic Design Methodology について、少し解説します。
なおそれぞれの用語については、読みやすさのため、なるべく以下のように日本語で呼称します。

Atoms → 原子
Molecules → 分子
Organisms → 有機体
Templates → テンプレート
Pages → ページ

Atoms (原子)
原子は Atomic Design の方法論の中で一番最小単位となるモジュールです。
どのWebページでも使用され得る、例えばボタンや input 要素、タイトルなどが該当します。
「UIとしてこれ以上分解できないもの」と捉えるとわかりやすいでしょう (図1-6)。

Molecules (分子)
原子が集まり、グループを形成したものが分子となります。
図1-7のように、先ほどはバラバラだった原子がグループを形成することにより、ひとつのモジュールとなったと考えるとわかりやすいでしょう。

Organisms (有機体)
次の単位となるのが有機体です。
有機体は分子だけでなく、原子や他の有機体も含むことが可能です。
比較的複雑なUIとなり、例えば図1-8のヘッダーは分子、原子を含む有機体であると言えます。

Templates (テンプレート)
ここでようやく、化学的な用語から離れてWebらしい用語となります。
テンプレートは今まで出てきたもののを組み合わせ、レイアウトを形成したものを指します。
実際に使用する画像やテキストなどのコンテンツは考慮せず、あくまでレイアウトや構造の定義に留まります(図1-9)。

Pages (ページ)
最後に定義されている単位がページです。
これは前述のテンプレートに、実際に画像やテキストなどのコンテンツなどを適用した形で、Webページとしてそのまま公開しても差し支えないものになっています (図1-10)。

なぜテンプレートとページを分離するかは、「同じレイアウトでもコンテンツが違う」というケースを想像するとわかりやすいでしょう。
例えば「利用規約について」「個人情報伝達方針」といたシンプルになりがちなページは、多くの場合レイアウトは同じですが見出したテキストなどのコンテンツは異なります。

Atomic Design を知る利点 p26

少しCSS設計から離れて Atomic Design の考え方を紹介しました。
なぜこのような遠回りをしたかというと、 Atomic Design に触れることによってズバリ「抽象思考」が身につくからです。

抽象思考が身につく
Webサイトにせよ何にせよ、出回っているものの多くはすでに形のできあがっている「具体的な」ものです。
これを何の指針もなく要素を分解していく、抽象化していくのはなかなか難しいものです。

例えば Web ページを分解したとき、
ヘッダー
コンテンツエリア
フッター
までの分解で止まってしまう人も多いでしょう。これはこれで間違いではありません。

しかし Atomic Design を知り、粒度の指針を手に入れると、さらなる分解が容易になります。
そして要素をさらに分解することで、より高度で複雑なUIにも対応できるようになります。

Chapter 3 「さまざまな設計手法」で各CSS設計を学んだ後で改めて Atomic Designに 触れてみると、より理解が深まる点もあると思います。
ですので、現段階ではあまりピン来なくても大丈夫です！ Atomic Design は書籍として出版されているほか、Web上でもすべての内容を読むことができます。
英語ではありますが、興味のある人は読んでみると、 Web 開発全般の設計に対する理解がより深まるでしょう。

https://shop.bradfrost.com/
http://atomicdesign.bradfrost.com/

2-4 よいCSS設計が目指す4つのゴール p40

それではようやく、本書の本題であるCSS設計の話に入っていきましょう。
まずは抽象的に、「よいCSSとは何か」を考えてみます。

その際に役立つ指針が「よいCSS設計が目指す4つのゴール」であり、
これは Google のエンジニアである Philip Walton 氏のブログで提唱されている考え方です。

この考え方はCSS設計について調べるとたびたび目にする有名なもので。
予測できる
再利用できる
保守できる
拡張できる
の4つのポイントが挙げられています。

CSS Architecture:
https://philipwalton.com/articles/css-architecture/

予測できる
「予測できる」とは即ち、「スタイリングが期待通りに振る舞うかどうか」「スタイリングの影響範囲が予測できるか」を意味しています。
新しいスタイリングを追加する、または既存のスタイリングを更新しても、自分の意図しない箇所に影響を与えないよう設計されているべきです。
小さなWebサイトではさして問題ではないかもしれませんが、数十ページ、あるいは数百ページからなる大きなWebサイトではこの考え方は必須のものとなります。

再利用できる
例えば既存のパーツを別の箇所でも使用したいとなったとき、コードをいちいち書き直したり上書きする手間がない状態が「再利用できる」状態です。
そのために、スタイリングはきちんと抽象化されており、また適切に分離されている必要があります。
「抽象化」「分離」と言われてもまだイメージが湧きづらいかと思いますが、後ほど紹介する OOCSS を理解すると、「再利用できる」が言わんとすることが掴めるかと思います。

保守できる
新しいモジュールや機能を追加・更新、あるいは配置換えしたとき、既存のCSSをリファクタリングする必要がない状態が「保守できる」状態です。
例えばモジュールAを追加したときに、すでにあるモジュールBに影響を与えて壊してしまうような状況は望ましくありません。

拡張できる
「拡張できる」CSSとは、CSSに携わる人が1人であっても複数からなるチームであっても問題なく管理できる状態を指します。
そのためには CSS 設計の規則はわかりやすく、学習コストが極端に高くない状態である必要があります。
最初は1人で開発を始めたとしても、Webサイトが大きくなったり複雑になればCSSに携わる人は自然と増えるのが現代の開発ですので、早い段階から「拡張できる」CSSとなっているかどうかを意識しましょう。

以上が、よい CSS 設計が目指す4つのゴールの意味するところです。
これから CSS 設計を学ぼうと思う人は現段階ではまだピンとこないかもしれませんが、今はそれで大丈夫です。

本書を読み進め、実際に自分で手を動かしてみてから再度このセクションを読み直してみると、言わんとしていることが何となく理解できるようになっていると思います！

CSS設計の実践と8つのポイント p42

では実際に先ほど挙げた「よいCSS設計が目指す4つのゴール」を実現しようと思うと、さまざまな工夫をしながらコードを書くことになります。
何の指標もなしに工夫をするのは考えることが多すぎて頭がこんがらがってしまいますが、実はどの方法も概ね次の8つのいずれかに該当します。

本書にてこの後紹介する、
OOCSS
SMACSS
BEM
PRECSS
いずれの設計手法においても、必ず8つのポイントのうちどれかに該当する規則を持っています。
本 Chapter 以降も「この規則・工夫は8つのうちどれに該当するか？」を繰り返し提示していきますので、ぜひこのセクションはいつでも開き直せるように印を付けることをオススメします。

1. 特性に応じて CSS を分類する
2. コンテンツとスタイリングが疎結合である
3. 影響範囲がみだりに広すぎない
4. 特定のコンテキストにみだりに依存していない
5. 詳細度がみだりに高くない
6. クラス名から影響範囲が想像できる
7. クラス名から見た目・機能・役割が想像できる
8. 拡張しやすい

1. 特性に応じてCSSを分類する p45

まずひとつ目は、 CSSの分類についてです。どういうことかというと、
例えば先ほどのリセットCSSや「リンクテキストは赤にする = a { color: red; }」などサイト全体の下地となるベーススタイルを「ベースグループ」とみなす
ヘッダーやフッター、コンテンツエリアを形成するスタイリングを「レイアウトグループ」とみなす
モジュールに関わるCSSを「モジュールグループ」とみなす
など、CSS の役割や特性に応じてグループ分けすることです。
各設計手法については後ほど Chapter 3 で詳しく解説しますが、この方法は SMACSS 、 PRECSS で採用されています。

またこの分類に付随して、モジュール名に接頭辞を付けて、どの分類になるかの目印にすることもよくあります。
例えばレイアウトに関するコードに対しては、 SMACSS では「l-」、 PRECSS では「ly_」の接頭辞がつきます。
モジュールの分類の場合は、PRECSSでは「el_」「bl_」の接頭辞を使用します。

「場所、状況」 == 「コンテキスト」 p53

先に挙げた「場所、状況」という言葉は、よく「コンテキスト(直訳すると『文脈』)」と呼ばれます。
この「コンテキスト」という言葉は CSS 設計だけでなく他のプログラミング言語においてもしばしば聞く言葉ですので、覚えておくときっと何かの拍子に役立つでしょう。

2. HTMLとスタイリングが疎結合である p53

次のポイントが 「HTML と疎結合である」 です。
疎結合という言葉が聞き慣れない方もいるかもしれませんが、意味としては「HTMLとの結びつきが強くない」「HTMLに依存していない」あたりになります。

逆にHTMLに強く結びついている、依存している状態のことを「HTMLと密結合である」と言ったりもします。
「密結合 / 疎結合」という言葉は CSS 設計に留まらず、プログラミング全般においてたびたび耳にしますので、ぜひ慣れておくとよいでしょう。

p56

「ペルソナとは？」の方はh3にもh4にもなり得るので、同じ方法でセレクターをh4のみにする訳にもいきません。
要素型セレクター使用する限りこの複雑で厄介な問題はつきまといますが、
解決方法はシンプルで、「要素型セレクターを使用しない」、つまり「HTMLとスタイリングの結びつきを弱める(==疎結合にする)」です。

例えば「ユーザーを考えた〜」の方に「title」というクラス名を、
「ペルソナとは？」の方に「sub-title」というクラス名を付けて、クラスセレクターを使用することで、この問題は容易に回避できます。

HTML とスタイリングが疎結合でない他のパターン p60

今までのモジュールとは関係ありませんが、もうひとつ、HTMLと疎結合でない(=密結合)状態を見てみましょう。

a[href="https://google.co.jp"] {
	color: red;
}

このスタイリングは「リンク先が https://google.co.jp であれば、文字色を赤にする」ということを表しています。
しかし、後から「Yahoo! JAPAN の場合も赤にしたい」という追加要望があるとどうでしょうか？
単純に考えれば、次のようグループセレクターを使用して対応できます。

a[href="https://google.co.jp"], a[href="https://yahoo.co.jp"] {
	color: red;
}

こういった追加要望がある度に、CSSに手を加えるのは面倒です。
属性セレクターを使用して、かつ「特定の文字列を持つ場合 (リンク先が Google または Yahoo! JAPAN の場合)」というのは、
グループセレクターの記述を増やさない限り他の文字色を赤にしたいパターンに対応できません。
そのため、属性セレクターの特定の値を使用してスタイリングすることも、基本的には避けるべきです。

3. 影響範囲がみだりに広すぎない p61

次に気を付けるべきは「影響範囲がみだりに広すぎない」です。
「みだりに」というところがポイントで、きちんと計算・考慮したうえで影響範囲の広いCSSを書いているのであれば、それはそれで構いません。
ベースグループのコードなどがそうですね。

しかし影響範囲の広い CSS に無駄なスタイリングなどが含まれていると、とても大変な思いをします。
新しいモジュールを作成するたびに無駄なスタイリングを打ち消すコードを書かなければならなかったり、
影響範囲の広いCSSを修正しようにも、文字通り影響範囲が広いので、どこで崩れなどが発生するかわかりません。
一度影響範囲の広いコードを書くと、プロジェクトはずっとその負債を抱え続けることになります※。

先に結論を言ってしまうと、解決策としては、
スコープを絞る (影響範囲を狭くする) 
影響範囲の広いCSSに含めるスタイリングは、なるべく最小限に留める
のいずれかになります。

このうち「スコープを絞る」について、モジュールのコードを使用して解説していきます。
※これは恐らく、CSS以外にも言えることでしょう。

4. 特定のコンテキストにみだりに依存していない p65

次のポイントは「特定のコンテキストにみだりに依存していない」です。
コンテキストとは「場所や状況」のことでした。
コンテキストに依存していると何が問題かというと、ズバリ「コンテキストが変わったとたん、コードが動かなくなる」ことです。

5. 詳細度がみだりに高くない p68

続いてのポイントは「詳細度がみだりに高くない」です。
詳細度が高い CSS は
セレクターの見通しが悪くなりがち
他の要素 (親要素など) に対する依存が多くなりがち
上書きが難しい
ゆえにメンテナンスの工数が増える
と、基本的にあまりいいことがありません。
「既存のCSSの詳細度が高すぎて上書きするのが手間で、仕方なく !important を使う」というのは誰しもが経験したことがあるのではないでしょうか？

!important を使用するとますます上書きが難しくなるので、
そうならないためにも、最初からなるべく詳細度を抑えておくのが、CSSを長く綺麗に運用する秘訣です。

実際に詳細度を低くするためのコツとしては、「セレクターはクラスセレクターを使用する」ことが基本です。
ID セレクターはそれだけで詳細度が高く、またHTML側で1ページ内で同一の値のIDは1回しか使えない制約がありますので、IDをスタイリング目的に使用するメリットはあまりありません。

6. クラス名から影響範囲が想像できる p70

次のポイントは「クラス名から影響範囲が想像できる」です。
Webサイトは大きくなればなるほどモジュールやその他のクラスも増えていきますので、
「このクラスを編集すると、どの程度の範囲に影響を及ぼすのか」をクラス名から判断できることはとても重要です。

「3. 影響範囲がみだりに広すぎない」でも触れましたが、影響範囲の広いコードというのはときにどうしても必要になってきますので、
「影響範囲が広いこと」が問題なのではなく、「影響範囲が狭いか広いか、クラス名からきちんとわかるようにする」ということが本セクションでお伝えしたいことです。

このポイントを見極めるコツは、ズバリ「HTMLだけ見て予想した影響範囲が、CSSでのスタイリングと一致しているかどうか」です。

7. クラス名から見た目・機能・役割が想像できる p78

先ほどの「6. クラス名から影響範囲が想像できる」にも似ていますが、
次のポイントは「クラス名から見た目・機能・役割が想像できる」です。例えば
title1
title2
title3
というクラスがそれぞれあったらどうでしょうか？
どのタイトルがどのような役割を果たすのか、まったく想像が付かないですよね。

これらのクラス名が
page-title
section-title
sub-title
であれば、CSSや実際の表示を見なくても、どのような役割を担っているかだいたい想像が付くはずです。

8. 拡張しやすい p85

最後のポイント「拡張しやすい」です。
Webサイトは「公開して終わりではなる。
公開後も運用が続き、その中で既存のページやモジュールに対する変更が発生することも珍しくありません。

しかし最初からすべての変更を完全に把握・予想することは不可能です。
であればページやレイアウト、モジュールなどそれぞれのCSSにおいて、「なるべく変更に耐えられるように設計しておく」ことがポイントとなります。
今までの 1 ~ 7 のポイントは、すべて「変更に耐えられるように」という部分につながっています。
そのための最後のポイントがこの「拡張しやすい」です。
コードを拡張しやすい状態に保っておくと、何か追加要望があった際も、ひとつのセレクターとひとつのプロパティを追加するだけで済んでしまうことが多くあります。

この「拡張しやすさ」については、
拡張しやすいクラス設計を行う (マルチクラス設計を採用する)
拡張用として作成したクラスは、機能・役割に応じて適切な粒度影響範囲を保つ
のふたつの観点があります。

「拡張しやすいクラス設計」について、まずは「シングルクラス設計とマルチクラス設計」の概念を掴まねばなりませんので、
一度今までのモジュールからは離れ、新たにボタンモジュールを例に挙げて解説します。
後者の「適切な粒度」に関しては、モジュールのリファクタリングの際に解説します。

改めてモジュールとは p102

改めてモジュールとは何かを考えた場合、
スタイルや粒度 (大きさ、単位)こそさまざまなものが Web サイトによってありますが、共通して言えることは「使い回すことを前提としたひとかたまりの単位」 です。
このモジュールという発想により、同じコードを何度も書かない効率的なWeb開発を実現します。

モジュールの粒度のばらつきが引き起こす問題 p102

モジュールはきちんと定義・運用することができれば Web 開発に劇的な効果をもたらしてくれるのですが、乗り越えるべきハードルとして粒度の問題があります。
というのも「サイト内で繰り返し登場するスタイルは、なるべく使い回したい」というのは多くの人の間での共通認識なのですが、
「ではどこまでの範囲がひとつのモジュールなのか」を考えた時に、人によってかなりのばらつきが生じます。

モジュール粒度の指針 p104

以上を踏まえてモジュール粒度の指針をご紹介しますが、「こうしておけば絶対正しい」という唯一の回答ではないことは、始めに断らせてください。
プロジェクトの性質によってモジュール粒度の最適解もそれぞれ異なります。

ただし筆者の経験上最低でも
最小モジュール…… ボタンやラベル、タイトルなどのシンプルな要素 (Chapter 5 にて解説)
複合モジュール…… いくつかの子要素をもつ、ひとかたまりの要素 (Chapter 6 にて解説)
というふたつの単位を強く意識することをオススメします。

このふたつについては Chapter 1 でご紹介した Atomic Design にも通ずるものがあり、
最小モジュールは Atomic Design の Atoms (原子) に、
複合モジュールは Molecles (分子) や Organisms (有機体) と概ね対応させることもできます。

例えば図2-23のメディアモジュールは「単なるひとつの複合モジュール」ではなくBさんの認識の通り、
「複合モジュールの中に、最小モジュールが埋め込まれている状態」と捉えることができます。

2-7 CSS設計の必要性 p106

今までのモジュールの粒度の話や CSS 設計の8つのポイントを読んで、
もしかすると「かえってコードを複雑にしているだけでは？」とも思われるかもしれません。

結局 CSS 設計の必要性はプロジェクトの性質に左右されるので、
例えば 1 ページだで一週間しか公開しないようなキャンペーンページには、極論ですがCSS設計は必要ありません。

しかし、逆にページ数が100ページを超えるような中規模以上の案件については「CSS設計のやり過ぎがちょうどいい」くらいに思っておいた方がいいでしょう。
それくらいの規模になると、必ずモジュールが想定しない使われ方をし始めるので、機能は適切に分離しておくに越したことはありません。

CSS 設計について確実に言えるとすれば、
小規模なサイトを想定したコードを中規模以上のプロジェクトに持ち込むことはできない(必ず破綻する)
中規模以上を想定してCSS設計をしたコードを小規模のプロジェクトに持ち込むことはできる
いきなり中規模のサイトでCSS設計をしようとしても、すぐには上手くできない
です。

来たるべき日のために、ぜひ小さなプロジェクトからでも中規模以上のWebサイトを意識して CSS 設計を練習しておきましょう。

どうしても初めは難しい気がするかもしれませんが、慣れてくると思考が整理され、今までとはまったく違った粒度でデザインカンプを見ることができるようになります。
何より自分の意図通りに設計ができ、いかなる変更にも耐えうるウェブサイトを作れたときの喜びはひとしおです！

CSS設計も結局は小さなことの繰り返しですので、1回でわからずとも焦らず、徐々に慣れていってください。

3-2 OOCSS p109

Chapter 1 、 Chapter 2 でも少し名前を出しましたが、
OOCSS (オーオーシーエス エス) は Object Oritented CSS (オブジェクト指向 CSS) の略で、 Nicole Sullivan 氏 によって提唱されました。

レゴのように自由に組み合わせが可能なモジュールの集まりを作ろう
そのモジュールの組み合わせでページを作成しよう
そのため新規ページを作るときも、基本的に追加のCSSを書く必要はない
という発想が提唱されており、この発想は他のCSS設計手法にも少なからず影響を与えました。

そのレゴのようなモジュールを実現するための具体的な手法として
ストラクチャーとスキンの分離
コンテナとコンテンツの分離
というふたつの原則が掲げられています。

http://oocss.org/
https://www.slideshare.net/stubbornella/object-oriented-css/

OOCSSのまとめ p115

以上、OOCSS 大原則であるふたつの考え方を解説しました。
OOCSSの歴史はかなり古く、また明確に規則と呼べるものも多くありません (公式サイトを見てもわかる通り、解説はかなり簡素です) 。

またこれから解説する CSS の設計手法は、基本的に大なり小なり OOCSS を参考にしつつ、さらに改良を加えたものです。
今日において OOCSS 一本で実案件の CSS 設計を行う、ということはあまり現実的ではないでしょう。

しかし逆に言えば、10年近く前に提唱された考え方が他の CSS 設計手法に取り込まれ、今でも使用されていることを考えると、
OOCSSが掲げた考え方は CSS 設計における「ひとつの真理」といっても過言ではないように思います。

CSS設計の基礎中の基礎となりますので、ぜひOOCSSの言わんとしていることを押さえておいてください。

3-3 SMACSS p116

SMACSS (スマックス) は Scalable and Modular Architecture for CSS (拡張可能でモジュール的なCSS 設計) の略で、 Jonathan Snook氏によって提唱されました。
CSSのコードを役割に応じてカテゴリ分けしたのが特徴で、以下5つのカテゴリについてそれぞれ規則が設けられています。

1. ベース
2. レイアウト
3. モジュール
4. 状態 (ステート)
5. テーマ

OOCSS で語られていた範囲は、 SMACSS における「モジュール」におおよそ該当します。
OOCSS がほぼモジュールのみにしか言及していないのに対し、 SMACSS はもっと幅広く、
実際に Web サイトを構築するうえでは欠かせないベースやレイアウトのコードの扱い方にまで言及しています。

https://smacss.com/

p117

なおルールというわけではありませんが、SMACSSではbodyの背景色をベースルールで設定することを強く推奨しています。
これは Web サイトを閲覧するユーザーが、ブラウザの機能を使って背景色を独自設定している場合、色によっては Web サイトが正常に閲覧できなくなる可能性があるためです。

SMACSS のまとめ p138

SMACSSはプロジェクトにおいて考慮しなければならない CSS の、おおよそ全体をカバーする規則を持ち合わせています。
その反面それぞれの規則はそこまで厳格ではありませんので、ある程度の柔軟性を持ちたい、比較的緩く開発をしたいというときは SMACSSが向いています。

ただし場合によっては規則が緩すぎて実際のコードの指針となりづらいこともあり、
その際はモジュールルールにOOCSSを取り入れたり、あるいは後述のBEMの一部を取り入れるなど、他の設計手法との組み合わせも多く見られます。

余談ですが、筆者も CSS 設計を始めたころはSMACSSとOOCSSの組み合わせに、
さらに自分のオリジナルの規則を組み合わせていました(それが後に、後述する PRECSS へと発展します)。

3-4 BEM p139

BEM (ベム) は Block, Element, Modifier の略で、 Yandex 社によって提唱されました。
ユーザーインターフェースを独立したプロックに落とし込んでいくことで、複雑なページであっても開発を簡単かつ、素早く行うことを目的としています。

OOCSSのように基本的にモジュールをベースにした方法論であるものの、その内容は他の設計手法に比べ厳格・強力です。
そのため世界的にもOOCSSに匹敵するほど名前が知られ、利用されています。
本書をお手に取られた方でも、名前だけは聞いたことがある人は多いのではないでしょうか。

BEMでは名前の通り、モジュールを
Block
Element
Modifier
という単位で分解し、定義しています。
またこれら Block ・ Element ・ Modiffer をまとめて「BEMエンティティ」と呼びます。

BEMについてはカバー範囲がCSSに留まらないため、本書ですべては語りきれません。
BEMに興味を持ち、もっと突っ込んで知りたい方は、ぜひ一度公式ドキュメントをご覧になってみてください。
公式ドキュメントを読む際の負荷をなるべく減らすため、本書においても解説のためのコードの多くは公式ドキュメントから引用します。
https://en.bem.info/

p156

また「b-color_red」という Modifier 名が文字色が白に変更しているとも予測できませんので、
例えば名前を「theme_caution (警告テーマ) 」としましょう。
そうすることで名前が持てる責任範囲が背景色だけでなく、色変更にまつわる全般に関する責任範囲となります。

※BEMでは特に色に関しては、「見た目そのまま」ではなく「どのような意味を持つか」の命名をすることを重視しています。
そのため、赤が使われる状況をここでは「警告」と仮定し、命名します。

BEMのその他の命名規則 p173

BEMの標準の命名規則は block-name__elem-name_mod-name_mod-val のように、
・英数字の小文字
・Element と Modifier はそれぞれ Blockの名前を継承する
・それぞれの区切りの中に複数の単語がある場合はハイフンひとつ
・Block と Element の区切りはアンダースコアふたつ
・Modifier のキーの区切りはアンダースコアひとつ
・Modifier の値の区切りもアンダースコアひとつ
という規則でした。

しかしBEMを採用するにおいて必ずこの命名規則に準じないといけないわけではなく、
Block・Element・Modifier単語のそれぞれがきちんと区別できれば命名規則をカスタマイズしてもよいとしています。

BEM の最後の解説として、 BEM のドキュメントにも掲載されている他の命名規則と、
「MindBEMding」と題されたブログ記事で有名になった命名規則をご紹介します。

https://csswizardry.com/2013/01/mindbemding-getting-your-head-round-bem-syntax/

MindBEMding p176

最後に MindBEMding を紹介します。
MindBEMding は正式な命名規則の名前ではなく、イギリスの CSS Wizardry 社が運営しているプログに投稿された記事のタイトルです。

ただし日本では、その記事の中で紹介されている命名規則を指すものとして認知されています。

以下がその命名規則です。
block-name___elem-name--mod-name (--val)

・Modifier の区切りはハイフンふたつ
・Modifierのキーは省略可能

あまり大きな違いはありませんが、重要なのは「Modifierのキーは省略可能」という点です。

BEM 本来の Modifier の書き方と、 MindBEMding で紹介されている Modifier の書き方を比較したのが次のコードです。

※ MindBEMding getting your head 'round BEM syntax 
https://csswizardry.com/2013/01/mindbemding-getting-your-head-round-bem-syntax/

<!-- BEM 本来の Modifier の書き方 -->
<a class="button button_size_s" href="#">ボタン</a>

<!-- MindBEMding で紹介されている Modifier の書き方 -->
<a class="button button--s" href="#">ボタン</a>

本来の書き方の「button_size_s」に対し、 MindBEMding の方では「button--s」とシンプルになっています。
しかし、これだけでも Modifier が何をするものなのか、何となく想像がつきますね。

このシンプルさから、 BEM 本来の書き方よりも MindBEMding にて紹介されている書き方を採用しているサイトも多く見受けられます。

BEM のまとめ p177

多くの規則や考え方があり「BEMって大変そう…」「気を付けることが多すぎて混乱しそう…」と思われるかもしれません。
しかしこれだけ規則が多いのはBEMが厳しいからではなく、むしろそうしないと CSS が悲惨な状態を招いてしまうからです。

そういった意味では規則が多い、ドキュメントが長いBEMはそれだけ信頼できるものでもあります。
興味のある方は、ぜひ公式のドキュメントを読んでみることをオススメします。
BEMを採用するにしろしないにしろ、BEMの考え方を理解することは、
必ずあなたがコーダー/エンジニアとしてレベルアップする手助けになるでしょう。

最後に、BEMを成功させるコツと、既存のプロジェクトにBEMを導入する方法をドキュメントから引用します。
※ https://en.bem.info/methodology/quick-start/

BEMはCSSだけではない p178

今まで BEM の CSS 設計にまつわる部分を中心に解説してきました。
しかし、BEMは実は CSS 設計だけをまとめた方法論ではありません。
CSS 設計の背景にあるファイルの出力方法やファイル構成、ひいてはファイルの出力ツールも提供しているため、
CSS に限らず、 HTML や JavaScript も含めた「モジュールベースの Web 開発手法」ということができます。
その全貌はなかなか高度でまたCSSから逸脱してしまうので本書では解説しませんが、興味のある方、
CSS 設計も包括するモジュールベースの開発環境を考えている方は、公式ドキュメントの 
・File structure
・Redefinition level
・Build
・Declarations
などの項を読んでみてください。

3-5 PRECSS p179

PRECSS (プレックス)は prefixed CSS (接頭辞付きのCSS) の略で、筆者が開発しました。
名前の通りすべてのクラス名に役割に応じた2文字の接頭辞を付けるのが特徴で、 OOCSS 、 SMACSS 、 BEM に強く影響を受けています。
今までご紹介した設計手法に目を通しておくと、より理解がしやすいでしょう。

PRECSSはCSSを役割に応じて下記6つのグループに分類し、それぞれについて規則を設けています。
1. ベース
2. レイアウト
3. モジュール
	a. ブロックモジュール
	b. エレメントモジュール
4. ヘルパー
5. ユニーク
6. プログラム

それだけでなく、PRECSSはベースグループ以外の各グループのクラスにおいて2文字の接頭辞が付いていればよいため、
開発要件に合わせて独自のグループを作成することも可能です。
※ http://precss.io/ja/

モジュールの上下間の余白を実装するヘルパークラス p203

モジュールの上下間の余白が、デザインである程度統一されていればモジュールに直接スタイリングすることも可能ですが、現実として完全に統一されていないことも多いでしょう。
例えば「カードモジュールの次にテキストが続く場合は余白を20pxにしたいが、他のモジュールが続く場合は、
詰まって見えてしまうため40pxにしたい」というデザイン上の都合は、至極もっともです。

その場合、モジュール自体に余白のためのスタイリングを行うのは現実的ではありませんので、
ヘルパークラスを用いて実装することを筆者はよく行っています。

ユニークグループ p205

ある1ページでしか使用されていないことを明示するグループです。
そのページでしか使われていないため、改修や運用の際に影響範囲を気にせずにスタイルを編集してよい目印になっています。
モジュールの大きさも自由です。
小さくても大きくてもかまいません。
ECSS以外の設計手法で、不要になれば迷わず削除できるCSSの目印を用意しているのは、筆者の知る限り他にありません。

例えばPRECSSのドキュメントの扉ページのような特別なページ (図3-23) に使用するのもいいですし、
通常のページ内でもモジュール設計から外れる場所 (例えば postion: absolute; が頻出するような場所)に使用するのもいいでしょう。

※ 本書では解説しませんが、簡潔にいうと本書で解説している設計手法らとまったく異なる、
「分離して管理する」という考え方をベースにした設計手法です (http://ecss.io/) 。

PRECSSのまとめ p209

後発で作成したこともあり、OOCSSやSMACSS、BEMの利点を取り入れつつ、
実際に業務を進めるにおいて弱点と思う箇所を改善しながらできあがったのがPRECSSです。
そのため強力なモジュールシステムは維持しつつも、イレギュラーな要件があった際に対応しやすい柔軟性も持ち合わせています。

特に、
・ユニークグループの存在により、影響範囲が明確なモジュールを定義できる
・必要に応じて、グループを追加することでPRECSS自体を拡張することができる
・PRECSSの命名規則をHTML/CSS/JavaScript 以外の環境にも使用することができる
というのは、他の設計手法にはない PRECSS 独自の強みと言えるでしょう。

日本人発の設計手法の元祖 FLOCSS p210

日本人が作成した設計手法として、PRECSSの前に谷拓樹氏によって提唱されたFLOCSS (フロックス)があります。
国内での知名度はとても高く、本書をご覧の皆さまの中にもFLOCSSをご存知の方が多いのではないでしょうか。

FLOCSS は Foundation Layout Object の頭文字とCSSの略で、
前述のOOCSSやSMACSS、BEM、さらにSuitCSSやMCSSからも影響を受けて開発されたものです。
下記の3つのレイヤーと、 Object レイヤーの子レイヤーによって構成されています。
また Layout 以降のレイヤーでは、それぞれのレイヤーに該当する要素に接頭辞を付けることが特徴です。

1. Foundation
2. Layout (接頭辞:1-2)
3. Object
i. Component (接頭辞:c-)
ii. Project (接頭辞:p-)
iii. Utility (接頭辞: u-)

※ https://github.com/hiloki/flocss
※2Dセレクターを使用する際は、 接頭辞は付けません。

特にモジュールの設計についてはBEMをベースにしつつも、
BEMほどセレクターや詳細について厳格ではないため、プロジェクトに応じて柔軟に対応できるのがFLOCSSの強みです。

またFoudation以外のレイヤーのモジュールすべてに接頭辞が付いている点は、
コードをぱっと見てもどのような役割を担っているか想像できるメリットがあります。
ドキュメントも日本語で記載されているため SMACSS と同等に導入しやすく、かつSMACSSよりも規則が明確であるため、複数人での開発や保守もしやすいでしょう。

公式ドキュメントが日本語で公開されており、また谷拓樹氏による書籍「Web制作者のためのCSS設計の教科書」内でもご本人が解説されているため細かい内容はそちらにお任せします。
FLOCSSだけでなくCSS設計全般についてもとてもよく解説されている本ですので、本書と合わせてご覧いただくと、CSS設計に対する理解がより深まるかと思います。

4-3 ヘッダー p217

ヘッダーのレイアウトは図4-4のようにふたつに分けて実装します。
外側……ヘッダー全体を括る要素。上部の余白の確保と、コンテンツエリアとの境界となるボーダーを実装するのに使用します。
内側……ヘッダー内において、コンテンツエリアと同等の横幅を実装するのに使用します。

なお内側の中に配置されているロゴやボタン、グローバルナビゲーションについては、
レイアウトそのものではなく「レイアウトエリア内に配置されたモジュール (コンテンツ)」が正しい解釈です。

PRECSSにおいてはレイアウトのコードにつられて、よくこれらも「ly_headerLogo」「ly_headerBtn」のように「ly_」の接頭辞を付けて実装する例を見かけるのですが、
これらはあくまでモジュールであるため、「bl_」または「el_」の接頭辞が適切です。

BEMにおいてはそもそもレイアウトとモジュールを区別せず、すべてにおいて基本単位はBlockとなります。
しかし、だからと言ってレイアウトとコンテンツにまつわるスタイリングを一緒くたにしてしまうとメンテナンス性の悪いCSSとなってしまいますので、レイアウトとモジュールの区別はきちんと付けておくべきです。

<!-- 外側にあたる要素 -->
<header class="header">
	<!-- 内側にあたる要素 -->
	<div class="header__inner">
		<!-- 以下、 レイアウトの中に配置されたロゴ・ボタン・ナビゲーションが続きます -->
	</div>
	<!-- /.header__inner -->
</header>

.header {
	padding-top: 20px;
	border-bottom: 1px solid #ddd;
}
	
.header__inner {
	max-width: 1230px;
	padding-right: 15px;
	padding-left: 15px;
	margin-right: auto;
	margin-left: auto;
}

背景色が交互になるパターン p228

コンテンツエリア1カラムの設計として、単純に背景色が同一なパターンだけでなく、背景色は横幅いっぱいに敷かれるイメージです。
図4-8のように、セクションごとに背景色が交互になるパターンも考えてみましょう。

<header class="header">
	(省略)
</header>
<main>
	<article>
		<section class="content">
			<!-- 以下、レイアウトの中に配置されたコンテンツが続きます -->
		</section>
		<section class="background-color-base">
			<div class="content">
				<!-- 以下、レイアウトの中に配置されたコンテンツが続きます -->
			</div>
			<!--/.content-->
		</section>
	</article>
</main>
<footer>
	(省略)
</footer>

.background-color-base {
	background-color: #efefef;
}

2 カラム設計 p231

最後のレイアウト設計はコンテンツエリアが2カラムの場合です。
図4-11のようなイメージで、ブログの記事詳細ページなどを想定してもらえるとわかりやすいでしょう。

<header class="header">
	(省略)
</header>
<div class="content content--has-column">
	<main class="content__main">
		<article>
			<h2 class="level2-heading">
				LinkedIn BtoB マーケティング必須ガイド
			</h2>
			<!-- 以下、レイアウトの中に配置されたコンテンツが続きます -->
		</article>
	</main>
	<aside class="content__side">
		<h2 class="level4-heading">
			最新記事
		</h2>
	</aside>
</div>
<!-- /.content -->
<footer>
	(省略)
</footer>


``` content のスタイリングに下記を追加 ```
.content--has-column {
	display: flex;
	justify-content: space-between;
}

.content__main {
	flex: 1;
	margin-right: 3.25203%;
}

.content__side {
	flex: 0 0 260px;
}


```メディアクエリ適用時 ```
@media screen and (max-width: 768px) {
	.content--hasColumn {
		flex-direction: column;
	}	

	.content__main {
		margin-right: 0;
		margin-bottom: 60px;
	}
}

1 display: inline-block p242

ボタンが使用される場面を考えたときに、単体で使用されることのほか、段落内でテキストとともに使用されるケースもあります。
そして多くの場合、段落で指定している文字揃え (text-align) の向きにボタンの位置も従うことが求められます。
このときに display プロパティを inline-block に設定していると、親の段落の text-align の値を継承するため、ボタンの揃えのためのCSSをいちいち書く必要がありません。

「いちいちCSSを書く必要がない」というのは開発の省力化になるだけでなく、
モディファイアやイレギュラーな指定をみだりに増やさないことでもあるので、CSS設計において重要な考え方のひとつです。

ホバー時のスタイルをフォーカス時にも適用する理由 p247

ホバー時のスタイリングを行っているセレクターを見ると、「:hover」の疑似要素だけでなく「:focus」と、フォーカス時のスタイリングも同様に行っています。
この指定は主に、キーボードのタブキーを押下してページ遷移を行うユーザーに配慮するためです。

特別に指定をせずともイベントを起こす要素にフォーカスした場合はブラウザのデフォルトスタイルのフォーカスリングが表示されます。
しかしこのフォーカスリングはユーザーの視力によって、または Web サイトで使われている配色によっては、変化に気付かない場合もあります。

図5-11 は上がフォーカスリングのみの表示、下がフォーカスリングに加えてホバー時のスタイリングも適用した例です。
下の方が、より変化がわかりやすいのではないでしょうか？

テキストと余白の関係 p285

先ほどのコラムで「セクション間は必ず100px空ける」という要件を満たすために margin- top: 100px; というスタイリングを行いましたが、
実はこの指定だと、実際には100px以上空いてしまいます。

なぜこのようなことが起こるかというと、これは line-height にまつわる仕様に起因します。
例えば今回の例では font-size: 1.75rem; (通常は28pxとして表示される) というスタイリングを行っており、
line-height は 1.5 という値が、 body 要素に対して設定したベーススタイルから継承されています。
これがどのように描画されているかを示したものが図5-25です。
※ https://html5experts.jp/takazudo/13339/

なんとなく、おわかりいただけましたでしょうか？

今回は line-height に 1.5 という実数を指定しているため、 line-height は 28px (font-size) * 1.5 = 42px となります。
そして行の上下には line-height - font-size から算出された値(ここでは14px)が、それぞれ割り当てられます。
今回の例では7pxですが、この7pxの部分を「ハーフリーディング」と呼びます。

つまり margin-top: 100px; としても、これにハーフリーディングの7pxが加わり、実際には107pxが上部に空いているように描画されてしまうのです。
7px程度であればまだ違和感は小さいかもしれません。
しかし、 line-height または font-size の値が大きくなればなるほどハーフリーディングの値も大きくなるので、
状況によっては想定した以上に余白が空いて見えてしまうことにつながります。

そのため、テキストの上下の余白の値を厳密にしたい場合は、ハーフリーディングを値を考慮してmarginなどを設定する必要があります。
今回の場合は、margin-top: 93px; で実際には 100px の余白が空く描画となります。

ちなみに図5-26からもわかる通り、今回は下線があるため margin-bottom には影響しません。
代わりに padding-bottom に影響しており、 CSS では padding-bottom: 10px; と指定していますが、実際には17pxがテキストと下線の間に空いています。

しかし、見出しモジュール自体に上下の余白を確保するための margin-top/margin-bottom を設定しないこともあるでしょう。
それでもなるべく余白を厳密に再現したい場合、筆者は 「margin-top: -7px;」とハーフリーディングの値をネガティブマージンとして見出しモジュールに設定しておくことがあります。

こうしておくと、他のモジュールの margin-bottom で余白を空ける際も、
いちいち後続の見出しモジュールのハーフリーディングを気にしなくてよくなります (そもそも「次に必ず見出しモジュールが来る」とも限りませんからね…) 。

次のコードと、図5-26のようなイメージです。
.el_txt {
	margin-bottom: 100px;
}

.el_lv2Heading {
	margin-top: -7px;
}

このような形で、図5-26では綺麗に「ほぼ100px」の余白が空きます。
「ほぼ」というのは、結局 .el_txt の方でも下のハーフリーディングの分の余白が100pxに追加されてしまっているためです。
これをすべて厳密にしようとするのは現実的ではありませんので、「本文程度の font-size と line-height であれば誤差とする (ので、対応しない) 」とどこかで一線を引くとよいでしょう。

余談ですが、いずれの場合でもハーフリーディングをいちいち計算するのが面倒なため、
著者はハーフリーディング算出用の関数を Sass で作成し、計算を自動化しています。
ただ本書の枠から外れてしまうため、今回はSassについては解説しません。

3 margin-right: 3.33333%; p298

この値は完成図の画像とテキストの余白である40pxを、メイン幅の1200pxで割ったものです (40/1200)。
左右の余白を % で指定することにより、スクリーンサイズを縮小した際に余白も小さくなるため、違和感のないレスポンシブウェブデザインを実現できます。

小数点以下の有効桁数 p301

今回、 
・flex: 0 1 27.58333%;
・margin-right: 3.33333%;
というとても細かい数値を指定していますが、果たしてこの小数点以下の桁数はどこまで有効なのでしょうか？
これは結論を先に言ってしまうと、「ブラウザ次第」ということになります。

margin-right をサンプルに筆者が執筆時点で調べたところ、
・Google Chrome (macOS、Windows)
・Firefox (macOS、Windows)
・Safari
はCSSの指定通り、 3.33333% が適用されています。

しかし、
・Internet Exproler 11
・Edge
においては、「3.33%」と、小数点第三位以降は切り捨てられていました。

また、CSSの指定として「3.33333%」を受け入れているにしても、実際に算出しているpxの値は
・Google Chrome: 39.984px
・Firefox: 39.9833px
・Safari: 39.98px
とブラウザによってバラつきがあることを確認しています。

これは何も今回のように「3.33333%」と小数点第五桁まで指定した場合だけでなく、あらゆる中途半端な相対値に起こり得ることです。
これらの誤差でブラウザによってはたまに段落ちなどを起こすことがあるので、すべてのブラウザにおいて統一された値が算出されているわけではないことを覚えておいてください。
※ちなみに筆者はこの桁数を自分で決めているわけではなく、基本的にSassの出力に任せています。

スクロールに慣性を与える -webkit-overflow-scrolling: touch; p345

水平方向のスクロールについて、特にスマートフォンを使用している際、ブラウザによっては慣性スクロールが効かない場合があります。
その場合、 -webkit-overflow-scrolling プロパティの値を touch にすることで、慣性スクロールを有効にすることができます。
今回のコードでは、次のように記述します。

※スワイプの強さに応じてスクロールの速度や量が変わる機能。
例えばはじくようにスワイプすると、スクロールの速度は速くなり、量は多くなります。

.bl_horizTable.bl_horizTable__mdScroll {
	border-right-width: 0;
	overflow-x: auto;
	-webkit-overflow-scrolling: touch;
}

しかしこのプロパティは標準仕様ではなく、正式にサポートしているブラウザも執筆時で iOS の Safari のみです。
他のブラウザで予期しない挙動を引き起こす可能性もありますので、使用する際はターゲットブラウザで十分に検証したうえで、自己責任で使用してください。

筆者の考えるベストプラクティス p458

以上4つの方法をご紹介してきましたが、筆者が考えるベストプラクティスは 1+ 場合によって 2 (または3) という形になります。

まず1ですが、これは各モジュールにあらかじめ「標準余白」を設定してしまう、というものでした。
すべてのモジュールに対して、デザインカンプに余白の指示があればいいのですが、あまりそういったプロジェクトに出くわしたことはありません。

ただしどのようなプロジェクトにおいても「標準余白」を設定しやすいモジュールがあり、それは即ち見出しです。
見出しは多くの場合セクションの区切りとなっており、「セクションの区切りは必ず80px空ける」というようなデザインカンプが多く見受けられます。

そのため、筆者は見出しに対して「セクション間の余白」として margin-top 、
後続するコンテンツとの余白として margin-bottom の両方を設定しておくことがよくあります。

.el_lv2Heading {
	margin-top: 80px;
	margin-bottom: 40px;
}

次に、他の各モジュールに対して標準余白がデザインカンプで定められていないとしても、予防線として、各モジュールに標準余白を入れておいてしまいます。
なぜかというと、万が一エンジニア以外の職種の第三者、またはクライアントが、こちらの意図しない形で既存のモジュールを組み合わせてページを編集したり作成したりした場合でも、
モジュール間の上下がくっつかず、最低限の見た目を担保できるようにしておくためです。

この値は、おおよそ margin-bottom: 30px; とすることが多いです。
30pxという値自体は完全に筆者の感覚値です。
同じ値を margin-top にも設定することもよいでしょう
(レイアウトに関するスタイリングがあまり多く付きすぎていると、
モジュールの再利用の際に邪魔になることがあるので、筆者は margin-top まで付けるのはあまり好みませんが……)。

ただしこれでは当然画一的過ぎてデザインカンプを再現できないことが多いので、
デザインカンプを再現するために2、または3のヘルパークラスを用いる方法を併用します。
2 のように毎回完全に自由に値を設定できるようにするか、または3のようにある程度のパターンを持たせるかについては、プロジェクト次第です。

以上、モジュールと余白の関係について解説してきました。
余白は結局デザインカンプに大きく左右される要素であるため、 CSS 設計の中でもかなり難しい部類に入ります。
筆者も今でもたまに悩み、もっといい方法はないかと模索することがあるため、上記4つの方法を参考にしつつ、ぜひご自身でも最適な方法を考えてみてください。

スタイルガイドジェネレーターを使用する p462

この「スタイルガイドジェネレーター」とはスタイルガイドを生成するツールの総称であり、世界中の有志の手によって数多くのソールが公開されています。
以下に、簡単ではありますが有名なスタイルガイドジェネレーターを紹介します。

・Fractal
・SC5
・kss-node
・Atomic Docs
・Stylemark
・Storybook

スタイルガイドを作成する方針のまとめ p478

中規模以上のプロジェクトである、または公開時は小規模であっても、
運用が進むにつれてのちのち肥大化することが予想されるのであれば、
Fractal などのスタイルガイドジェネレーターを使用してモジュールを管理した方がよいでしょう。

ただし、そこまでの仕組みが必要でない場合は手動で作成する方法も十分有用です。
そしてスタイルガイドが存在しないよりは、手動で作成したものでもあった方が必ずよいです。

最後に、スタイルガイドで一番重要なことはきちんとアップデートし続けることです。
これはスタイルガイドジェネレーターによる生成であっても、手動作成であっても変わりません。

そして継続的にアップデートし続けるには、簡単に運用できる仕組みも不可欠です。
スタイルガイドジェネレーターも一度覚えればそこまで難しくはありませんが、ときに複数人が関わったり、人が入れ替わることもあるでしょう。
そういったことが発生することも踏まえて、スタイルガイド運用のための簡単な社内向けドキュメントの作成も検討したい事項です。

スタイルガイドジェネレーター・手動どちらの方針で作成するか
スタイルガイドジェネレーターを利用するにしても、どのツールが機能的にちょうどよいのか、運用できそうか
などをきちんと吟味したうえで、選択できるのがベストです。

p481

Sassについては大変奥が深く、きちんと解説するとそれだけで一冊の本ができあがってしまいます。
幸い「Web制作者のためのSassの教科書」という非常によい書籍がすでに出版されておりますので、Sassについてもっと知りたい方はこちらをご参照ください。

CSScomb p484

https://github.com/csscomb/csscomb.js/

CSScomb (シーエスエスコーム) は主にCSSのプロパティの並び順を整理するツールです。
CSScomb用の設定ファイル「.csscomb.json」を作成し、プロジェクトのルートディレクトリに設置したとしましょう。
.csscomb.json の中身は、次のようになっているとします。
※CSScomb に限らず、開発時に使用する多くのツールの設定ファイルは、ファイル名がドットから始まります。

"sort-order": { 
	"position",
	"z-index",
	"top",
	"right",
	"bottom",
	"left",
	"display"
}

EditorConfig p485

※ https://editorconfig.org/

EditorConfig (エディターコンフィグ) はコードの記法を統一するためのツールです。
エディタが EditorConfig に対応している必要がありますが、現在使用されている主要なエディタの多くが EditorConfig に対応しているくらい、標準的なツールとなっています。

例えば次のような EditorConfig 用の設定ファイル「.editorconfig」を作成し、プロジェクトのルートディレクトリに設置したとしましょう。
※エディタによっては、プラグインを追加することで EditorConfig に対応できます。

# プロジェクトのルートに設置する .editorconfig か
root = true

# 改行コードと、ファイルの末尾に空行を入れるかの指定
[*]
end_of_line = lf
insert_final_newline = true

# CSS と HTMLのインデント指定
[*.{css,html}]
indent_style = space
indent_size = 2

CSS Stats p489

※ https://cssstats.com/

CSS Stats (シーエスエススタッツ) はこれまでのツールとは打って変わって、ブラウザ上で使用する Web サービスです (図9-1) 。

ここに解析したいページの URL を入力し「Go」ボタンを押すと、
そのページで使われているCSSルールの数やセレクター数、使用されている色、フォントサイズなどさまざまな情報を一覧してみることができます (図9-2) 。

・色は多すぎないか
・フォントサイズが乱立しすぎていないか
などさまざまなリファクタリングのヒントを得ることができるだけでなく、改めてこうして一覧で見るのは単純に面白さもあります。
息抜きがてら、ぜひ一度試してみてください。

CSS MQPacker p492

https://github.com/hail2u/node-css-mqpacker

CSS MQPacker (シーエスエス エムキュパッカー) はメディアクエリの記述をまとめてくれるツールです。
まずはコードを見た方が早いと思うので、次の実行前のコードと実行後のコードをご覧ください。

sort オプションを使用する p495

これは Gulp や npm-scripts などの設定ファイル内で、 CSS MQPacker の実行に対してオプションを指定しておく方法です。

もしメディアクエリが min-width のみで、かつ使用している単位が ch ・ em ・ ex ・ px ・ rem のどれかであれば、
sort オプションを true にすることで自動的にスクリーンサイズが小さい順になるようメディアクエリをまとめてくれます。

CSS MQ Packer 実行時の設定例 
postess([
	mgpacker ({
		sort: true
	})
])

さらに自由に並び順をカスタマイズしたい場合は、 sort オプションに無名関数を渡すことで制御ができますが、
JavaScript の領域になってしまうため本書ではこれ以上は解説しません。

p497

CSS MQPacker は上手くハマればファイル容量を削減できる非常に有用なツールではあるのですが、
これらの問題が発生するリスクもあることをご留意ください。
メディアクエリをまとめるのは、想像以上に大変なんですね。

cssnano p497

https://cssnano.to/

cssnano (シーエスエスナノ) は CSS を圧縮するためのツールです。
単純に圧縮するだけでなく、

・ショートハンドで表現可能なものはショートハンドに変換
・重複したプロパティの削除
・値の短縮化
など、プロパティや値の無駄もチェックしてくれるのが特長です。
※改行や不要な空白を取り除き、ファイル容量を軽くすることです。