【CSS設計】class名の決め方（命名規則）やコーディングする時の考え方を解説

コーディングを勉強中の方から「HTMLをどうパーツ化してclass名を付ければ良いかピンとこない」のような悩みをよく聞きます。

HTML/CSSの設計をミスるとコーディング後半で思い通りにいかなくなって、!importantを使ったり変なクラスを追加したりなど、無理やり汚いコードを書く羽目になってしまった...という経験は誰しも一度はあるはずです。

HTML/CSSは自由度が高くあまり綺麗でないコードでも動いてしまいます。しかし、汚い状態でどんどんコーディングをすると、もっとコードが汚くなり、可読性が悪くなり、いつの間にか○○のレイアウトが崩れていた...のような負のスパイラルに陥ることも起きます。

今回は、そのような負のスパイラルに陥らないようになるためにも、class名の決め方（命名規則）やコーディングする時の考え方を解説します。

CSS設計の基本

• 予測しやすい
• 再利用しやすい
• 保守しやすい
• 拡張しやすい

Googleのエンジニアの方が、上記のように唱えています。

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

今回は、この4つに則り解説していきます。

予測しやすい

Predictable CSS means your rules behave as you’d expect. When you add or update a rule, it shouldn’t affect parts of your site that you didn’t intend. On small sites that rarely change, this isn’t as important, but on large sites with tens or hundreds of pages, predictable CSS is a must.

あらかじめ決めたルールに則ってコーディングをする、予測できない書き方はしない

HTML/CSSは一貫性（ルール）を持たせます。コーディング前にしっかりとルールを決めます。

• .c-から始まるクラス名は共通パーツ（c = component の略）
• 同じパーツのスタイルは、CSSファイルの同じ箇所にまとめて書く

のようなルールを決めたら、そのルールに則りコーディングをします。

「CSSの○○を変えたら、サイトの××が変わる」と直感的に分かるのが理想です。

再利用しやすい

CSS rules should be abstract and decoupled enough that you can build new components quickly from existing parts without having to recode patterns and problems you’ve already solved.

サイト内で使い回せるパーツは、使い回せるような仕組みにする

CSS設計の基本は、いかに使い回せるようにパーツを作るかです。

.button {
  color: #f00;
  font-size: 20px;
  background-color: #00f;
  width: 200px;
  margin: 20px auto;
}

ボタンが共通パーツだとして、上記のように.buttonに全てのスタイルを書いてはいけません。

/* 見た目 */
.button {
  color: #f00;
  font-size: 20px;
  background-color: #00f;
}


/* 構造 */
.service-button { /* サービスページではボタンを小さくしたい */
  width: 200px;
  margin: 20px auto;
}

.outline-button { /* 概要ページではボタンを大きくしたい */
  width: 300px;
  margin: 40px auto 0;
}

このように「見た目」と「レイアウト構造」のクラスを分けてしまえば、ページによって変わるかもしれないwidthやmarginにも対応できます。

「見た目」と「レイアウト構造」を分けるコツとしては、コーディングを始める前にサイト全体のデザインを見て、共通化できそうな箇所をチェックしておきます。コーディングを始めたら、最初に共通化できるパーツから作って（見た目を作る）、その後に共通化したパーツを配置します（構造を作る）。

保守しやすい

When new components and features need to be added, updated or rearranged on your site, doing so shouldn’t require refactoring existing CSS. Adding component X to the page shouldn’t break component Y by its mere presence.

運用時に既存のCSSの修正は必要最低限に、影響範囲は分かりやすいようにする

以下のように、修正したときの影響範囲を考えないでコーディングをすると、いざ修正する時にとても大変です。Aの見た目を変えたいのに、BやCの見た目も変わってしまう...ことが無いように設計しましょう。

拡張しやすい

As your site grows in size and complexity it usually requires more developers to maintain. Scalable CSS means it can be easily managed by a single person or a large engineering team. It also means your site’s CSS architecture is easily approachable without requiring an enormous learning curve. Just because you’re the only developer touching the CSS today doesn’t mean that will always be the case.

他のメンバーが初めてコードを触っても、簡単に仕様を把握して修正や機能の追加ができるようにする

自分だけが分かればいいや精神はNGです。自分以外の誰かがコードを触っても理解できるようなコードを書くようにしましょう。

複雑な仕様があるならコメントやドキュメントを残すのも重要です。実装中はどんな仕様だったか覚えていても、1ヶ月も経てばその仕様は覚えていないものです。未来の自分自身や他のメンバーのためにも、ドキュメントを残すのはとても大事なことです。

・・・

CSS設計の基本の「予測しやすい」「再利用しやすい」「保守しやすい」「拡張しやすい」を踏まえ、次はコーディングする時の注意点や意識することを解説していきます。

CSSの詳細度は全てのスタイルで同じにする

CSSの詳細度についてよく分からない方はこちらをご覧ください。

エンジニアはもう一度CSSとちゃんと向き合ってみよう - 詳細度編

CSSの詳細度は全てのスタイルで「同じ」にしたいので、原則「ひとつのクラスのみ」で指定します。

/* クラス一つのみで指定してるからOK */
.text { ... }

/* idや親要素、セレクタなどを使ってるからNG */
p .text { ... }
.parent .text { ... }
#wrap { ... }
#wrap .text  { ... }

詳細度を全てのスタイルで同じにしたい理由は、CSSファイル内で「上」より「下」に書いたスタイルの優先度が高くなるからです。

詳細度が同じ場合、上より下に書かれたスタイルが優先されます。このようにルール化することで、詳細度によるCSS上書き問題が発生しなくなります。

初心者がよく陥る点として「詳細度がめちゃくちゃで仕方なく!importantを使ってしまう」が挙げられます。全てのスタイルで詳細度を同じにすれば、このような問題は起こりません。

「ひとつのクラスのみ」でコーディングするイメージが湧かない方は以下の例をご覧ください。

/* サービスページのタイトル */

/* これまでの書き方 */
.page-service .title { ... }

/* ひとつのクラスのみの書き方 */
.service-title { ... }

全ての要素にクラスを付ける（一部例外）

前項の「CSSの詳細度は全てのスタイルで同じにする」を実現するには、全ての要素（スタイルを当てる要素）にクラスを付けなければいけません。

なので、基本的には全ての要素にクラスを付けます。

そもそも、タグに依存する書き方（例：p { color: #f00; }）をすると、タグが変わったらCSSも修正しなければいけないので、良い設計とは言えません。

インライン系の要素にはクラスは付けなくても良い

「全ての要素にクラスに付ける」と書きましたが、インライン系の要素にはクラスは付けなくても良いです。

span, a, img, b, strong, em...など

経験上、これらのインライン系のタグは、タグが変わることはありません。なので、タグに依存する書き方をしても問題ないです。

また、aタグやimgタグにはhrefやsrcといった属性が付くので、さらにクラスを付けるとコードが見にくくなってしまいます（個人的感想）。

なので私は、インライン系のタグにはクラスは付けなくても良いと考えています。

コードが長くなるのを気にしない

CSS設計を意識してコーディングしていると、ボタンのクラス名を今まではclass="button"と書いていたのをclass="service-button button primary"のように書くことになり、違和感を感じるかもしれません。

しかし、破綻しないコードにするために、コードが長くなるのは仕方のないことです。むしろ、少ないコードで書いて破綻するほうが問題です。

同様の理由で、divやspanなどが多くなって入れ子が以前より深くなることもあると思います。意図があれば何も問題はないので、コードが長くなるのは気にしないようにしましょう。

要素の見た目に合うクラス名を付ける

ブログの記事一覧などの各記事の「サムネイル」にクラス名を付けるときは.imgや.thumbを付けると思いますが、もし.iconがついていたらどうでしょう？

他の人からすれば、cssファイルの.iconのスタイルを変えてどこかのアイコンの見た目を修正したつもりが、実際はサムネイルの見た目が変わってしまいます。

誰が見ても一目で要素と紐づくようにクラス名を付けましょう。

正しく、簡単な、長過ぎない英単語を使う

使う英単語は難し過ぎないほうが良いです（以前、中学3年までに習う英単語にするのがオススメというのを聞いたことがあります）。ある程度の人が理解できるような英単語が一番望ましいです。

長い日本語を英訳すると複数の単語になる場合は、助動詞を省略したり、単語同士をハイフンで繋げると良いでしょう。

契約詳細 → Google翻訳 → Contract details → クラス名：contract-detail
募集要項一覧 → Google翻訳 → List of application requirements → クラス名：app-requirement-list や requirement-list

単語を略すかどうか論争

単語は「略すべき」「略さないべき」とTwitterで議論になることが多々あります。

ボタンのクラス名の場合、略したら「btn」、略さなかったら「button」になります。

私は、誰もが予測できる略し方ならOKだと思っています。「誰もが予測できるかどうかを自分ひとりで判断するべきじゃない」と突っ込まれそうですが、「ボタン→btn」「タイトル→ttl」くらいなら別に良いと思います。（正直どっちでも良いです）

丁寧なコードを書く

ここで指す「丁寧」とは、CSS設計が丁寧で綺麗という意味ではなく、「コードのインデントが揃っている」や「HTMLを正しく入れ子にしている」という意味です。

// 綺麗な例

<div class="parent">
  <p class="text">text</p>
  <div class="block">
    <a href="">
      <img src="" alt="">
    </a>
  </div>
</div>



// 汚い例
// インデントや入れ子がめちゃくちゃ
<div class="parent">
      <p class="text">text</p>
      <div class="block"><a href=""><img src="" alt="">
        </a>
        </div>
      </div>

インデントや入れ子がめちゃくちゃだとミスの原因にもなります。コードレビューをしてもらう立場の場合、見る側からしたらストレスしか感じません。

エディタの自動整形ツールを使うでも良いので、丁寧なコードを書くように心がけましょう。

個人的にはaタグやimgタグも入れ子にしたい派です。

// こうじゃなくて...
<p><a href=""></a></p>

// こうしたい
<p>
  <a href=""></a>
</p>

公開後に気づいたのですが、「丁寧なコードを書く」はCSS設計とは全く関係なかったですね...。一応大事なことなので消さないでおきます...。

まとめ

これらの内容を意識してコーディングをできるようになれば、実務でも通用するレベルになると思います。

今回はあえて命名規則を取り入れたCSS設計（BEMやFLOCSSなど）については触れませんでした。今回紹介した内容をしっかりと理解できたら、次はBEMなどを取り入れてコーディングをしてみると良いでしょう。

▼ BEMなどが気になる方はこちら
【CSS設計手法】BEM、OOCSS、SMACSSの違いと特徴のまとめ