模写修行メディア

【CSS設計入門】class名の決め方(命名規則)から具体的な書き方まで詳しく解説

【CSS設計入門】class名の決め方(命名規則)から具体的な書き方まで詳しく解説

この記事をシェア:

実務でリニューアル案件や改修案件をやると、他人が書いたコードをよく見ることになります。これは"ヤバイ"と思うコードもたくさん目にします。

HTMLは色々な書き方があってOKというわけではなく、正しく意味付けするものなので、ちゃんと書いていれば人によってあまり差が生まれません。一方で、CSSは人によって書き方はかなり様々です。

  • どんなサイトを作るのか
  • 誰が作るのか
  • サイト公開後は誰が保守・運用するのか

これらによって最適な書き方は変わってきます。正解はありませんが、CSS設計を理解して、自分の中でどんなCSS設計を採用するかは決めておくべきです。

この記事では、CSS設計に関して、具体的なサンプルも用いて解説します。

CSS設計が大事な理由

小規模案件やLPなどでは、それほど明確なCSS設計をしなくても問題は起こらないかもしれません。

書き方によってサイトのパフォーマンスが変わるなんて話しもありますが、昨今のブラウザではその差はほんの誤差程度なのでその点も無視して良いでしょう。

ただ、規模が大きくなるとHTMLもCSSもかなりの量になり、CSS設計をせずに書くといずれ破綻します。複数人で制作する場合も、CSS設計がないとほぼ確実にひどいコードになります。

ココ重要!
webサイトやwebサービスは公開してからがスタートです。公開後の運用も考えて、良いコードを書くことはとても重要です。

良いCSSとは?

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

Googleのエンジニアである、Phil Waltonさんが自信のブログで、良いCSSとして4つを上げています。

翻訳したものを記載します。CSS 設計を初めて勉強する方は、ざっと目を通すだけでも良いです。しっかり勉強した後に見直すと、理解が深まると思います。

予測しやすい

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.

予測可能な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ルールは抽象的であり、十分に分離されている必要があります。これにより、すでに解決したパターンや問題を再コーディングすることなく、既存のパーツから新しいコンポーネントをすばやく構築できます。

保守しやすい

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をリファクタリングする必要はありません。 コンポーネントXをページに追加しても、コンポーネントYが存在するだけで壊れてはなりません。

拡張しやすい

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.

サイトのサイズと複雑さが増すにつれて、通常、より多くの開発者が維持する必要があります。 スケーラブルなCSS は、1人または大規模なエンジニアリングチームが簡単に管理できることを意味します。 また、膨大な学習曲線を必要とせずに、サイトのCSSアーキテクチャに簡単にアクセスできることも意味します。 今日CSSに触れている開発者があなただけだからといって、常にそうなるとは限りません。

カスケーディングと詳細度の理解は必須!

駆け出しの方々のコードを見て、1番問題だと感じるのが、『カスケーディングと詳細度』を意識していないことです。

カスケーディングと詳細度を理解して、その上で適切なルールで書けば、大きな問題は防げます。

カスケーディングとは?

Cascadeとは日本語で滝という意味です。CSSのカスケーディングとは、滝のように上から下へ連鎖的に伝わる仕組みのことです。

先に宣言されたものが継承されたり、後に書いたもので上書きされたりする仕組みのことです。

例を紹介します。


💡 継承される例

body{
  font-size: 18px;
}

.service-text{
  color: blue;
}

.service-textは文字色が青色になるだけでなく、bodyに指定したフォントサイズも継承されます。

※継承されるかどうかはプロパティによります。


💡 上書きされる例

.service-list{
  color: red;
}

.service-list{
  color: blue;
}

.service-listに対して同じプロパティ(color)が指定されています。この場合、後に書いたものが先に書いたものを上書きするので、color: blue;が適応されます。

詳細度とは?

CSSは単に後に書いたものが先に書いたものを上書きするわけではなく、詳細度という優先度のルールがあります。

  1. !important
  2. インライン記述
  3. IDセレクタ
  4. クラスセレクタ、属性セレクタ、擬似クラス
  5. 要素セレクタ、擬似要素
  6. ユニバーサルセレクタ

詳細度はこれらの順に高くなります。

#service .service-list{
  color: red;
}

.service-list{
  color: blue;
}

このコードでは、後に書いているcolor: blue;で上書きされません。それは先に書いている方が詳細度が高く、優先されるからです。

ルールを設けずにCSSを書くと、この詳細度が複雑になります。

詳細度のルールはもう少し複雑ですが、長くなるのでここでは解説しません。後述しますが、基本は単体のクラスセレクタに対してスタイリングすれば複雑になることはありません。

詳細度の計算ができるサイトを載せておきます。

CSSでidは使わない方が良い?

前述した詳細度の仕組み的に、idは基本使いません。

有名なCSS設計で、特定条件では使っても良いとしているものもありますが、使うことのメリットは特にありません。

もちろんページ内リンクの飛び先になるタグにはidが必要です。それでもidにはスタイリングしな方が良いです。

<header id="header" class="header">...</header>

スタイリングが必要な場合、このようにして.headerに書きます。

IdをJavaScriptのフックに使う方もいます。

<div id="js-kv-slider">...</div>

JavaScriptを書く際にはこのidを指定します。この使い方は特に問題ないです。ただし、#js-kv-sliderにスタイリングをするのはNGです。あくまでJavaScriptのフックのためのidです。

JavaScriptのフックでもclass=”js-kv-slider”のようにclassで指定しても良いです。

CSSの命名規則

命名規則に関しては正解はありません。ルール化されていればなんでも良いです。好みの問題も大きいと思います。

ただし、気をつけた方が良い点もあるので紹介します。

classの単語名に困った時に参考になる記事も載せておきます。

命名規則は統一する

  • キャメルケース
  • スネークケース
  • ケバブケース

この3つは命名規則でとても有名です。

<!-- キャメルケース -->
<div class="cardTitle">...</div>

<!-- スネークケース -->
<div class="card_title">...</div>

<!-- ケバブケース -->
<div class="card-title">...</div>

どれを採用するかは好みの問題です。

<!-- アンダーバーを2つ使う -->
<h2 class="card__title">...</h2>

<!-- モディファイヤー(ハイフンを2つ使う) -->
<h2 class="card-title card-title--large">...</h2>

<!-- モディファイヤー(ハイフンから始まる) -->
<h2 class="card-title —large">...</h2>

また、後述しますが、CSS設計によっては、アンダーバーやハイフンを2つ使うものがあったり、ハイフンから始まる classがあったりもします。

どんな命名規則を採用したとしても、統一されているかには気を配りましょう。

class名は意味のわかる名前にする

🙆‍♂️ 良い例

  • contact
  • kv-main-copy
  • submit-button

🙅‍♂️ 悪い例

  • otoiawase
  • aaa
  • btn1

ローマ字や意味のない文字列は辞めましょう。

連番に関しては、ルールが決まってれば良いと思います。1番目には連番は付けず、2番目から.hoge02のように付ける方が多いように感じます。

単語はできる限り省略しない

🙆‍♂️ 良い例

  • title
  • text
  • button

🙅‍♂️ 悪い例

  • ttl
  • txt
  • btn

わかるものは省略可としてる方もいるので、この辺も個人差はあります。

ただ、わかりやすいに越したことはないので、一切省略しないルールが無難ではあります。

見た目や場所ではなく意味でつける

🙆‍♂️ 良い例

  • footer-site-info
  • text-attention

🙅‍♂️ 悪い例

  • footer-left
  • text-red

場所や見た目をclass名にすると、後で変更になった時に、名前と合わなくなる可能性があります。

どうやっても色や場所でしか区別しようがない...なんてこともありますが、出来る限り意味で付けるのがベストです。

マルチクラスとシングルクラス

マルチクラスとシングルクラスでどちらを採用するかも、各プロジェクトごとに統一させるべきです。どちらが良いかはそのプロジェクトによります。

  • マルチクラスの場合はHTMLが複雑になる
  • シングルクラスの場合はCSSが複雑になる

このように、どちらもシンプルに書く方法はないので、トレードオフです。

マルチクラス

<div class="col-md-4 text-muted bg-success"></div>

マルチクラスとは1つの要素に対して、複数の class を指定するものです。Bootstrap や Tailwind CSS はマルチクラスです。

Tailwind CSSのスクリーンショット]

こちらはTailwind CSSのサイト内で紹介されているサンプルです。個人的にHTMLがこんなことになるのは気持ち悪くて無理です。

管理画面など、コンポーネント(同じ見た目の部品)化できるパーツが多いサイトでは、マルチクラスで運用した方がコード量は少なく、綺麗に書けるかもしれません。

シングルクラス

<div class="header-item"></div>

シングルクラスとは1つの要素に対して、1,2つ程度のclassを指定するものです。

ページごとにレイアウトが大幅に変わるようなwebサイト制作では、マルチクラスだと上書きが多くなります。また、classが大量にできてしまう可能性があるので、シングルクラスが適している場合が多いです。

よく見るダメな書き方

よく見るダメな書き方を紹介します。

HTML・CSS の入門書でもこれらの書き方をしていることもあるので注意が必要です。

要素セレクタに対して装飾している

p{
  text-align: center;
  font-size: 20px;
}

このように要素セレクタに対してCSSを書くと、全てのpタグにこのスタイルが効きます。

ある所では違う装飾をしたい場合、それを打ち消すために上書きする必要があります。結果、コードが複雑になり、コード量も多くなります。

リセットCSSを除けば、要素セレクタに対して装飾する必要があるケースはかなり限られます。


💡 要素セレクタに対して装飾してOKな例

body {
    line-height: 1.8;
    font-size: 14px;
    color: #333;
    font-family: ...;
}

a {
    text-decoration: none;
    color: inherit;
}

img {
    width: 100%;
    height: auto;
    vertical-align: bottom;
}

HTMLに依存している

.contact > div > div{ ... }
.contact h2{ ... }

例えばこのようなコードがあるとします。

今は問題なくても、今後HTMLの修正が入った際、CSSも修正が必要になる可能性があります。また、タイトルがh3に変わるケースも考えられます。

なるべく修正箇所が少なくなるように、CSSはHTMLに依存しない書き方をするべきです。

無駄に詳細度が複雑になっている

#service .service-item{}
li.service-item{...}

これらの書き方は詳細度を複雑にするだけで、良いことは何もありません。

.service-item{...}

このように基本は全て単体のクラスセレクタに対してスタイリングすれば、詳細度は複雑になりません。

サンプルを交えて代表的なCSS設計を紹介

  • OOCSS
  • SMACSS
  • BEM

ここではこれらの代表的なCSS設計を紹介します。日本で生まれたFLOCSSとPRECSSも使っている方が多いイメージです。FLOCSSとPRECSSに関しては最後の『おすすめの書籍や記事』で紹介します。

しっかり解説するとかなりの長さになってしまうので、概要だけ紹介します。興味がある方は公式のドキュメントなどで勉強してみてください。

独自のCSS設計を採用している方も、ここで紹介する考え方を一部採用していたり、組み合わせていることが多いです。

OOCSS

OOCSSはObject Oriented CSSの略で、オブジェクト指向にもとづいたCSS設計です。

Twitter、Github、Youtubeなどで採用されているCSS設計です。普段Bootstrapを使っている方は理解しやすいかもしれません。

レゴのパーツのようにはめていきながら、webサイトを作るような設計になっています。

  • 構造(structure)と見た目(skin)
  • コンテナ(container)とコンテンツ(contents)

OOCSSではこのような分け方をします。

例を用いて説明します。


💡 構造(structure)と見た目(skin)で分ける

<button class="button submit">送信</button>
<button class="button return">戻る</button>
.button{
  width: 200px;
  height: 60px;
  line-height: 60px;
  ...
}

.submit{
  background-color: #333;
  color: #fff;
}

.return{
  background-color: #ddd;
  color: #333;
}
  • 構造:button
  • 見た目:submit / return

このように分けることになります。


💡 コンテナ(container)とコンテンツ(contents)で分ける

/* 🙅‍♂️ NGな例 */
.contact button{
  ...
}

/* 🙆‍♂️ OKな例 */
.button{
  ...
}

コンテナ(container)とコンテンツ(contents)で分けることは、言い換えると使用する場所を限定させないということです。

NGな例では、.contactの中でしか使えず、再利用性出来ません。


  • 構造と見た目で分ける
  • コンテナとコンテンツで分ける

表現は違う場合もありますが、これらの考え方は他のCSS設計でも使います。

デザインのルールがしっかり決まっているサイトはOOCSSのようなマルチクラスと相性が良いでしょう。

SMACSS

SMACSSはScalable and Modular Architecture for CSSの略で、OOCSSやBEMを参考に作られています。

  • Base
  • Layout
  • Module
  • State
  • Theme

SMACSSではコードをこの5つのカテゴリに分類します。

コードを役割ごとに分類する考え方は、他のCSS設計でも採用されています。個人的にも分類はした方が良いと思います。

/* Base */
...

/* Layout */
...

/* Module */
...

/* State */
...

/* Theme */
...

コードを書く際は、このように分類ごとにコメントで区切ると良いです。

5つのカテゴリについて紹介します。


💡 Base

body {
    line-height: 1.8;
    font-size: 14px;
    color: #333;
    font-family: ...;
}

a {
    text-decoration: none;
    color: inherit;
}

img {
    width: 100%;
    height: auto;
    vertical-align: bottom;
}

デフォルトスタイルやリセットCSSなどが入ります。


💡 Layout

.l-header{
  ...
}

.l-sidebar{
  ...
}

.l-footer{
  ...
}

.l-container{
  ...
}

headerやfooterなどのページのレイアウトを作る要素が入ります。接頭辞には l-をつけます。


💡 Module

.button {
  ...
}

.title {
  ...
}

.card {
  ...
}

再利用可能なパーツが入ります。モジュールはコンポーネントと同じ意味です。


💡 State

.is-menu-active {
  ...
}

.is-text-hidden {
  ...
}

JavaScriptの操作などによる、特定の状態を示すスタイルが入ります。接頭辞には is-をつけます。


💡 Theme

.theme-dark {
  ...
}

サイトテーマを切り替えられるような仕様にする際に使います。接頭辞にはtheme-をつけます。

例えば、ダークモードに対応したサイトでは、ダークモード適応時にbody.theme-darkをつけて、スタイルを変更するような使い方をします。

BEM

BEMはBlock Element Modifierの略で、おそらく1番有名で使われているCSS設計手法だと思います。

分類詳細
Block大枠となる独立した要素
ElementBlockを構成する要素
Modifierバリエーションクラス

Block / Element / Modifierをどう区切ってclass名にするかは、人それぞれです。Block__Element–-Modifierのように区切る方が多い印象です。

単語の区切りはハイフンを使います。

<li class="header__item">トップ</li>
...
<li class="header__item">会社概要</li>
<li class="header__item header__item--contact">お問い合わせ</li>
  • Block 👉 header
  • Element 👉 item
  • Modifier 👉 contact

上のコードは、このように分類できます。Modifierでcontactを作ったのは、contactだけ重要なリンクとして他より目立つスタイリングをするためです。


💡 使用例

sample
<header class="header">
  <h1 class="header__logo">
    <img src="..." alt="...">
  </h1>

  <nav class="header__nav">
    <ul class="header__list">
      <li class="header__item">トップ</li>
      ...
      <li class="header__item">会社概要</li>
      <li class="header__item header__item--contact">お問い合わせ</li>
    </ul>
  </nav>
</header>

どこをブロックでどこをエレメントにするかの判断は人それぞれです。この例では、header__navをブロックと捉えて、header-navとするのも間違いではありません。ブロックの中にブロックが入ることも問題ありません。

ブロックとエレメントの分け方の基準として、参考になるサイトを載せておきます。

自分の関わるプロジェクトや好みに合わせてカスタマイズするのがベスト

CSS設計にはどのプロジェクトでも最適な唯一無二な正解はありません。

  • アニメーションが多いリッチなサイトを制作する機会が多い
  • 業務系の管理画面を作ることが多い

極端な話し、これらの2パターンでは、良いCSS設計は変わってきます。

この記事ではいくつか有名なCSS設計を紹介しましたが、それらをそのまま使っている人は少ない印象です。多くの人が少なからず、自分好みにカスタマイズしているのではないでしょうか。

勉強中の方はいきなりCSS設計を取り入れると混乱するかもしれません。いずれしっかり学ばないといけないこととして、頭に入れておくだけでも良いでしょう。

CSS設計に加えて、SCSSやタスクランナーも学べば、保守性も担保した上で効率の良い開発が出来るはずです。

【初心者向け】模写修行流CSS設計を紹介!

上の記事では、初学者向けの独自のCSS設計手法を紹介しています。

おすすめの書籍や記事

おすすめの書籍や記事を紹介します。


書籍はこの2冊がおすすめです。この2冊を読んで、あとは実践で考えながらコーディングをすれば、良い書き方が見えてくると思います。

『CSS 設計完全ガイド』を書いた半田惇志さんはPRECSSの考案者、『Web 制作者のための CSS 設計の教科書』を書いた谷拓樹さんはFLOCSSの考案者です。


吉本さん(@tsuDoi220)のサイトです。ここまで詳しく自分の手法を公開している方は少ないので、現役の方の設計手法を見れるのはとても参考になります。


TAKさん(@tak_dcxi)の500円の有料noteです。1から学ぶ系の記事ではありませんが、かなり実務向けで500円と価格も安いので、おすすめです。


はにわまんさん(@haniwa008)のzennの記事です。

CSS設計の勉強がしたい方は「模写修行」を!

模写修行

コーディングの練習が出来るサービス「模写修行」を作りました。

模写修行はこんな方におすすめ!

  • 基礎学習を終えて実践的な経験を積みたい
  • 破綻しない書き方を学びたい(= CSS設計を意識したコーディングを学びたい)
  • 実務と同じようにXDのデータを見ながらコーディングの練習をしたい
  • 現役で制作をやっている人のコードを見たい

この記事で紹介したようなCSS設計を使用した教材になっています。基礎学習を終えて実践的な"練習"がしたい方は、是非覗いてみてください。

この記事をシェア:

模写修行のトップページのスクリーンショット
模写修行

駆け出しエンジニアのためのコーディング練習教材