【実務向け】CSSのclass名の決め方(命名規則)はどうすればいいか?について解説

この記事の目次

実務でリニューアル案件や改修(修正)案件をやっていると、他人が書いたコードをよく見ることになります。正直、悪い意味でヤバイと思うコードもたくさん目にします。笑

htmlよりcssのほうが、人によって書き方は様々だと感じます。htmlは色々な書き方があってOKというわけではなく、正しく意味付けするものなので、ちゃんと書いていれば人によってあまり差がないのは当然ですね。

僕は仕事をする上で効率的な書き方を自分なりに模索しながらやってきたため、結構自己流だったりもしますし、自分が受ける規模の案件に最適化されているかもしれません。

案件によって最適な書き方は変わってきますが、自分の中で決まったルールを設けておいたほうが良いです。また、会社や案件によってはコーディング規約があり、細かなルールが決まっていることもあります。

今回はそんなルールの中でも重要な項目の1つである、cssのclass名の決め方(命名規則)について紹介します。

CSS設計にも触れた無料コーディング練習教材も作ったので興味がある方は是非!

CSS設計が大事な理由

正直、小・中規模案件くらいだと、それほど明確なcss設計をしなくても問題は起こりません。

書き方によってサイトのパフォーマンスが変わるなんて話しもありますが、昨今のハイスペックなブラウザではその差はほんの誤差程度なのでその点も無視して良いでしょう。(もちろん小・中規模案件でもちゃんとcss設計するのがベストです。)

ただ、大規模案件になるとhtmlもcssもかなりの量になり、css設計がないと保守性が悪くなってしまったり、意図しないところに影響してしまったりします。また、複数人で制作する場合、css設計なしに各々が好き勝手に書くとコードがえらいことになります。

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

一般的にこの4つが良いcssの定義とされています。

どんな案件にも対応出来るように、cssの設計について学んでおくことは大切です。がっつり勉強したい方は下記の本がおすすめです。

また、吉本 集さん(@tsuDoi220)の吉本式BEM設計(BEM設計ベース)もとても参考になります。

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

勉強を始めたばかりだとあまり聞かないかもしれませんが、idは使わない方が良いという意見があります。実際に僕が以前受けた案件のコーディング規約でも、idの使用を制限しているものもありました。また、有名な命名規則でもidは使いません。

使わない方が良いとされる、代表的な理由はこんなところでしょう。

  • 1ページに同じid名は1つだけしか使えず、再利用できない
  • classよりもidに書いたコードが優先されるので併用すると、優先度が複雑になる

もちろんページ内リンクの飛び先になるタグにはidが必要です。

また、javascriptのイベントのフックに使う人もいます。例えば、id=”js-kv-slider”のようなidをつけておいて、javascriptを書く際にはそのidを指定するものです。

因みの僕たちのコーディング規約では、idを使って良いのはページ内リンクのみです。javascriptのフックもclass=”js-kv-slider”のようにclassで指定します。

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

命名規則の中でマルチクラスとシングルクラスという言葉が出てくるので、ここで解説しておきます。

マルチクラス

マルチクラスとは1つの要素に対して、複数のclassを指定するものです。Bootstrapなんかはマルチクラスですね。後ほど紹介する、OOCSS、SMACSSもマルチクラスに分類されます。

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

シングルクラス

シングルクラスとは1つの要素に対して、1,2つ程度のclassを指定するものです。後ほど紹介する、BEMはシングルクラスに分類されます。

html
<div class="item"></div>

命名規則に関わらず守るべき事項

class名の命名規則には有名所で、BEM、OOCSS、SMACSSなどがあります。そのどれを使ったとしても、または独自の命名規則を採用するにしても、ここで紹介することは守ったほうが良いです。

※日本語NG、全角NG、スペースNGなど超基本的なことは除いています。

有料になってしまいますが、TAK / Web Creator.(@tak_dcxi)さんのnote(僕がCSSを書く際に必ず意識している CSSのコーディングルール30条)はおすすめです。かなり実務向けで500円と価格も安いので、しっかり学びたい方は買ってみるといいです。

要素名に対して装飾しない

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

このように要素名に対してcssを書くと、全てのpタグにこの装飾が効いてしまいます。ある所では違う装飾をしたいと思ったら、それを打ち消すために要素名に対して書いたcssを上書きする必要があります。その結果、コードが複雑になり、コード量も多くなります。

例えばaタグの下線を消すなど、全てに共通で効かせたいものであれば良いのですが、そうではない場合は要素名に対して直接cssを書くのは辞めた方が良いでしょう。

もちろんリセットcssなどで使うのはOKです。

class名は意味のわかる英語にする

良い例

  • contact
  • main-copy
  • submit-btn

悪い例

  • otoiawase
  • aaa
  • btn1

セマンティックなclass名をつけましょう!と解説されてるサイトも多いです。『意味のわかる』=『セマンティックな』ということです。

ローマ字や意味のわからない名前はやめましょう。書いてる時はよくても、後でコードをいじる際に分かりにくくなります。また、支障はなくてもカッコ悪いですよね。『あーこれ作った人は適当な人だな』とか、『あまりスキルないんだな』と思われてしまいます。

ハイフンとアンダースコアを統一する

良い例

  • main-copy
  • sub-copy

悪い例

  • main-copy
  • sub_copy

流石にこんな書き方をする方はあまりいないような気もしますが…

命名規則によっては1つのclassの中でハイフンとアンダースコアどちらも使うことがありますが、それぞれのルールは明確に決まっています。明確なルールなしに、ハイフンとアンダースコアを混同させるのは良くないです。

htmlに依存しない書き方をする

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

css
.contact > div > div{ ... }

今は問題なくても、今後htmlの修正があった際にこの書き方だとcssも修正しないといけなくなる可能性があります。そのような書き方は避けるべきです。

命名規則ではないけどインデントや改行は統一する

統一感のある書き方をすることも大切です。とにかく綺麗に見やすく!
例えば下記のようなコードは汚くて良くないです。改修案件ではこんなコード良く見ます。笑

css
.kv-logo {
  width: 200px;
}
.kv-main-copy{
  font-size: 30px;
  font-weight: bold;
  color: #333333;
  margin-bottom: 20px;

}

.kv-sub-copy{
  font-size: 20px;
color: #666;
}

統一感を持って下記のようにすると良いでしょう。

css
.kv-logo{
  width: 200px;
}

.kv-main-copy{
  font-size: 30px;
  font-weight: bold;
  color: #333;
  margin-bottom: 20px;
}

.kv-sub-copy{
  font-size: 20px;
  color: #666;
}

インデントや改行は揃っていれば特に絶対こうしなくてはいけないといったことはないです。また、marginなどの余白も常に下につけるなど、自分でルールを決めておくことも大切です。

プロパティ名をアルファベット順にしている方もいますが、僕はそこまではしません。

代表的なclass名の命名規則

有名で良く使われている命名規則を紹介します。

独自の命名規則を採用している場合も、ここで紹介する3つの命名規則の考え方を一部採用していたり、組み合わせていることが多いです。

BEM

BEMはBlock Element Modifierの略で、1番多く使われている命名規則だと思います。因みに僕もBEM推しで、BEMのルールを少し変えた独自の命名規則を採用しています。

Block:大枠となる独立した要素
Element:Blockを構成する要素
Modifier:BlockやElementをスタイリングするもの

この3つに分けて、class名はBlock__Element–-Modifierとします。ハイフンとアンダースコアは2つです。ハイフン1つの場合はElementとModifierの区切りではなく、ただの単語の区切りとして使います。

使用例

sample

html
<div class="service">
  <div class="service__item">
    <h2 class="service__item-ttl">ここにタイトルが入る</h2>
    <p class="service__item-txt">テキストが入る。テキストが入る。</p>
    <a href="#" class="service__item-link service__item-link--red">MORE</a>
  </div>

  <div class="service__item">
    <h2 class="service__item-ttl">ここにタイトルが入る</h2>
    <p class="service__item-txt">テキストが入る。テキストが入る。</p>
    <a href="#" class="service__item-link service__item-link--yellow">MORE</a>
  </div>

  <div class="service__item">
    <h2 class="service__item-ttl">ここにタイトルが入る</h2>
    <p class="service__item-txt">テキストが入る。テキストが入る。</p>
    <a href="#" class="service__item-link service__link--green">MORE</a>
  </div>
</div>

基本的にページをまたいでの再利用しない前提なので、classの影響範囲の把握がしやすいです。

従って、cssを修正したら、思わぬところにも影響したなんてことは起きません。ただやっぱり見た目が汚いですよね…。htmlはなるべくシンプルに、汚さず!がモットーなので気持ちは悪いですが、保守性なども考慮すると良いcss設計かなと思います。

OOCSS

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

Twitter、Github、Youtubeなどで採用されているcss設計で、普段Bootstrapを使っている方は理解しやすいかもしれません。(BootstrapはTwitter社が開発したフレームワークです。)

開発者のNicole Sullivan氏は『レゴの集まりで考えよ』と言っています。レゴのパーツのようにガッチャンガッチャンとはめていくイメージです。

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

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

使用例

html
<div class="nav-links"> 
  <a class="link link-blue">前の記事</a> 
  <a class="link link-red">次の記事</a> 
</div>
css
.link{
  width: 200px;
  height: 60px;
  line-height: 60px;
}

.link-blue{ 
  background-color: #00f; 
  color: #fff; 
}

.link-red{ 
  background-color: #f00; 
  color: #fff; 
}

構造:link
見た目:link-blue / link-red
コンテナ:nav-linksのついたdivタグ
コンテンツ:linkのついたaタグ

このようになっています。   コンテナとコンテンツの分離がわかりにくいので、補足すると。

コンテナとコンテンツを分離していないcssの書き方

css
.nav-links a{
  width: 200px;
  height: 60px;
  line-height: 60px;
}

コンテナとコンテンツを分離したcssの書き方

css
.link{
  width: 200px;
  height: 60px;
  line-height: 60px;
}

分離している方は使用する場所を限定されていないことがわかると思います。分離していない方はnav-linksの子要素に限定されてしまいます。OOCSSではこのように使用する場所を限定される書き方はNGです。場所を限定させないために、コンテナとコンテンツは分離します。

OOCSSは再利用性を意識した設計です。この考え方はコード量が少なくて済み、class名もシンプルで良いのですが、cssを変更した際にページをまたいで複数箇所に影響するので、その影響範囲を把握しにくくなります。

SMACSS

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

Base:デフォルトスタイル。リセットcssなどもここに当たる
Layout:header ,footer などのページのレイアウト、接頭辞にはl-をつける。例) l-header
Module:レイアウトの構成要素であり、再利用可能なパーツ
State:特定の状態を示す、接頭辞にはis-をつける。例) is-active
Theme:サイトテーマ全体の外観を示す、接頭辞にはtheme-をつける。例) theme-color

この5つに分類されます。

OOCSSと同じように再利用性を意識した設計で、コード量が少なくて済み、class名もシンプルですが、影響範囲を把握しにくい問題はあります。

自己流でも明確なルールがあればOK

これは賛否両論あるかもしれませんが、自己流でも下記の3つを守っていれば良いかなと思います。実際、独自の命名規則を設けている会社もたくさんありますし。

  • 明確な命名規則である
  • 他人が見てもざっくり命名規則がわかる
  • 保守性を考えた命名規則

僕はOOCSS、SMACSSを使って上手いこと書ける気がしないです。笑

管理画面やwebサービスであればOOCSS、SMACSSでもうまくいく気がしますが、HPやLPなどのwebサイトでは影響範囲に関する問題が起こりそうです。(使ったことありませんが。)

命名規則をちゃんと意識するのは、基礎的なことがある程度出来てからでOKです。htm,cssの勉強中の方は、命名規則なんてものがあるんだと頭に入れておいて、いずれ勉強すれば良いと思います。

最後に効率的に書きたければ、絶対にSassも導入しましょう。この辺の話しはいつか別の記事で書こうと思います。

Share