こんなHTMLとCSSのコーディング規約で書きたい

HTML と CSS のコーディングルールを作ろう

HTML と CSS のコーディング規約を中心に、メンテナンス性の良い HTML や CSS をコーディングする際に重要だと思うポイントをまとめています。

誰に向けた記事か

この記事には、HTML や CSS を書く人に役立ちそうな内容が書いてあります。
特に初級者から中級者の方で、HTML や CSS を一通り学習した方からの反応が良いです。

まだ HTML や CSS の学習を始めて間もないという方は、先に案件やプロジェクトをこなしコーディング経験を積むことをお勧めします。経験を積むとよりこの記事の内容への理解が深まるはずです。

HTML と CSS を書くときに大切なポイント2点

HTML と CSS を書くときに大切だと思うことを書きます。

1. HTML と CSS を書かない

あなたがいま書いている HTML と CSS は、本当に書く必要があるものなのでしょうか？

近年、Bootstrap のような高品質な CSS フレームワークが多くリリースされています。HTML ・ CSS のフレームワークを利用すれば、HTML や CSS を書かずに望むデザインを実現できます。ムダな HTML や CSS を書かず、コーディングのコストを減らすことで、プロジェクトが成功する確率は高まります。

2. 増やすより減らす

HTML を追加、あるいは CSS を上書きしてデザインを修正したくなった経験は誰にでもあるでしょう。そのような場面では、HTML と CSS を減らすことで対応できないかを考えます。

なぜなら、HTML の追加や CSS を上書きしていくと、HTML と CSS のメンテナンスコストが上昇します。メンテナンスコストの上昇はプロジェクトの成功にネガティブに働きます。ムダなdivを減らし、 CSS の追加をやめ、HTML と CSS をなるべく減らすように工夫することでメンテナンスの負担を軽減させ、プロジェクトの成功率を高めることが可能です。

メンテナンス性が高い HTML と CSS を書く

HTML と CSS のコーディングでは、メンテナンス性を高くすることが何よりも大切だと考えています。

メンテナンス性が高い HTML と CSS とは

メンテナンス性が高い HTML と CSS は以下の4点のポイントがあります。

• わかりやすい
• 探しやすい
• 再利用しやすい
• 拡張しやすい

本記事では、上記を満たす書き方をコーディング規約に組み込むことで、メンテナンス性の高い HTML と CSS を実現することを目的としています。

コーディング規約を決める

コーディング規約を決めることで、HTML と CSS の品質を揃えることが可能です。

規約は品質を揃える

HTML と CSS は人によって書き方がバラバラです。

コーダーはネストがやたら深いスタイルや汎用クラスを使いたがり、プログラマは HTML 内にインラインスタイルを書きたがる傾向にあるとおもいます。多様な書き方があります。

Web のプロジェクトは、多様なバックグラウンドを持つ人が関わりますので、品質を揃えるためにコーディング規約の導入が望ましいです。規約を書いても大したコストにはなりませんし、規約から得られるメリットはコストを上回ります。

規約は絶対に守らなければならないものではない

規約は絶対に守るべきことではないと考えています。時として理想とはいえない解決策をとる羽目になることもある、HTML と CSS のコーディングはそのようなものだとおもいます。

例えば、規約のないまま複数のコーダーによってマークアップされているプロジェクトに、途中から参加することもあります。

このような場合、全体に渡るコーディング規約の導入は難しくなります。まずは一部から、規約を導入すると良いでしょう。

今すぐ規約を試すには？

実は、すぐにコーディング規約を試す方法があります。
Google の HTML / CSS のコーディング規約が公開されているのでそのまま使ってください。
https://google.github.io/styleguide/htmlcssguide.html

この規約をそのまま使えば、基本的には間違いありません。
当記事で紹介している規約は、Google の規約をベースとしています。

その他にも大企業などがスタイルガイドを公開していることがあるので参考にしてください。

• https://github.com/styleguide
• https://www.starbucks.com/static/reference/styleguide/

クラスの命名に BEM を使う

CSS ではクラスの命名が、メンテナンス性に重要な影響を及ぼします。

クラスの命名に関しては、BEM というフロントエンドの設計手法が、CSS の厳格な命名ルールになっているので、BEM を採用します。
BEMは一見いけてないコーディング規約ですが、煩雑になりがちな CSS の世界に秩序をもたらすことに役立ちます。

BEM って何？！という方には、BEM のコーディングについて以下を挙げておきます。参考としてご覧ください。

• https://github.com/juno/BEM-methodology-ja

BEM ではクラスをBlock、Element 、Modifer として表現します。なるべくクラスの名前だけで HTML 要素の意味を伝えられるようにします。

Block（ブロック）

親の要素となるような要素をBlockとして命名します。

Block

.item
.item-list
.form
.form-search
.form-search-item /* ブロック名は２つ以上単語が繋がる場合があります */

Element （エレメント）

Element は Block に内包される部品です。Element が集まったものが Block になるので、Element は Block 内部に存在します。

Element

.item__text
.item-list__btn
.form__input
.form-search__title
.form-search-item__user

Modifier（モディファイア）

Modifier は状態を表すときに使用されます。同じ部品、同じ Block や Element で色だけ変えたい場合など Modifier を使用します。

Modifier

.item--red
.item-list__btn--type_success /* btnエレメントのうち、typeのキーがsuccessのモノ */
.form__input--active
.form-search__title--hover
.form-search-result__user--following

Modifier は状態をキーとバリューとして持つことができます。ただし、必ずキーとバリューを持たなくてもよく、バリューだけでも構いません。

単語のセパレータ

BEM でクラスを判別するためには、セパレータの使い分けが大切です。

単語の区切り

単語の区切りには - を利用します。

.main-content

2単語からなるクラスをハイフンを使って表現します。

BlockとElement の区切り

単語の区切りには __ を利用します。

.result__item

Element の区切りをアンダースコアを2つ繋げて表現します。

Block or Element とModifierの区切り

単語の区切りには -- を利用します。

.result--item

Modifierの区切りをハイフンを2つ繋げて表現します。

Modifierのキーとバリューの区切り

キーとバリューの区切りには _ を利用します。

.result__state_active

Modifierのキーバーリュー区切りにはアンダースコアで表現します。

HTML と CSS の基本記述

まず、CSS の記述方法をリファクタリング例と合わせて記述します。

CSS はクラスに記述する

CSS は基本的にクラスのみに記述します。また、HTML エレメントに指定せず、クラスを制限する書き方を避けるようにします。

HTML エレメントに CSS を書くと打ち消しのための CSS が増える

CSS の入門書籍を見ると、最初は HTML タグに CSS をあてる例が必ず出てきます。しかし、実はこの手法はオススメできません。 HTML タグに CSS をあてると何が問題になるでしょうか。

まずはダメなパターンを見てみましょう。以下に HTML タグに CSS をあてた例を書いてみます。

見出しタグ

<h1>タイトル</h1>

h1タグにスタイルをあてます。

改善余地あり

h1 {
  background-color: #EEE;
  border: 1px solid #222;
  color: red;
  margin-bottom: 1em;
  padding-top: 1em;
}

上記はありがちで普通の CSS に見えます。

ここで、あるページでボーダーと背景色がないh1タグを使用したくなったとします。その場合、 border と background-color を打ち消すクラスを書くことになります。

ボーダーと背景色がない見出しタグ

<h1 class="negative-bgc-b">タイトル</h1>

改善余地あり

h1 {
  background-color: #EEE;
  border: 1px solid #222;
  color: red;
  margin-bottom: 1em;
  padding-top: 1em;
}

.negative-bgc-b {
  background-color: none;
  border: none;
}

やりました。これでボーダーと背景色がないh1タグを書くことができます。

しかし、このフローこそ残念な CSS コーディングの始まりだと思います。

上記の例では negative-bgc-b というクラスで打ち消しをしている箇所が問題です。肥大化している CSS を見ると、ほとんどが重複を打ち消すための CSS で占められています。つまりどういうことかというと、HTML エレメントへ CSS を書くと、いずれ CSS を打ち消すための CSS を書く羽目になることを表しています。 CSS を打ち消すよりも、打ち消し CSS を書かずに実現する方法を検討することが大切です。

次は、クラスのみに CSS を書いた例を見てみます。

ボーダーと背景色がない見出しタグ

<h1 class="headline">タイトル</h1>

改善案

.headline {
  margin-bottom: 1em;
  padding-top: 1em;
}

.headline--piyo {
  background-color: #EEE;
  border: 1px solid #222;
  color: red;
}

h1 タグへ headline クラスを指定するだけで同じスタイルになっています。改善余地ありとした CSS が7行あったのに対し、改善案では CSS の行数が5行になり、2行減少していることがわかります。

つまり、HTML エレメントに指定する CSS を減らすと、結果的に将来ニーズが生まれる打ち消すための CSS コードを減らすことになります。HTML エレメントに CSS を書きたい誘惑に駆られた時は必ずこのことを思い出してください。

新しくスタイルが必要な場合は、上記のBEM の頁で述べたようにModifierのクラスを用意し、スタイルを追加する作業フローにします。このフローで実装すると CSS 全体のコード量を減らすことができます。

制限された CSS を書くと再利用性が下がる

改善余地あり

div.modal {text-align: left;}
p.content {padding: 10px;}

改善案

.modal {text-align: left;}
.content {padding: 10px;}

上記の例では、クラスのみでスタイルを指定したほうが短く記述できます。div .modalのように div に制限したクラスを書くと、.modalは div タグでしか使用できなくなります。.modalの使用が制限されているため、再利用性が低下しています。

例のように div や p とタグ指定をすると、 CSS の再利用性が低下します。つまり、CSS 内でのタグ指定は避けるようにすることで CSS が改善するかもしれません。

クラス名をわかりやすくする

クラス名を単語から想像しやすいクラス名にします。

改善余地あり

.mf80 {margin-right: 80px;}
.bcg { background-color: gray;}

改善案

.mr-80 {margin-right: 80px;}
.bgc-gray {background-color: gray;}

mf80 や bcg というクラス名は、短すぎるために意味が予想しにくいです。クラス名から要素の意味や、スタイルが想像できるでしょうか？
今回はスタイルが想像できそうなクラス名に変更しました。

CSS プロパティはアルファベット順

CSS プロパティを上からアルファベット順で記述します。アルファベット順に書くと簡単です。

改善余地あり

.block {
  width: 800px;
  margin: 80px;
  color: red;
  background-color: #FFF;
}

改善案

.block {
  background-color: #FFF;
  color: red;
  margin: 80px;
  width: 800px;
}

一方で、改善余地ありのように CSS プロパティの役割ごとに、記述順をまとめる手法があります。コチラは書き手によってクオリティにばらつきがでるので好ましくないとします。

HTML タグと CSS のインデントは半角スペース2

半角スペース2のインデントを使用して HTML と CSS を整形します。タブは使用しません。

改善余地あり

  <div class="tooltip"><div class="tooltip-arrow">
</div>
　　　<div class="tooltip-inner">ツールチップのテキスト
      </div></div>

上記の HTML は、インデントがされておらず、わかりにくい HTML です。

改善案

<div class="tooltip">
  <div class="tooltip-arrow"></div>
  <div class="tooltip-inner">
    ツールチップのテキスト
  </div>
</div>

半角2のスペースでインデントをつけました。インデントをつけることによって、可読性が向上し、タグが探しやすくなりました。

次は CSS の例です。

改善余地あり

.block {         background-color: #FFF;
color: red;
             margin: 80px;
      width: 800px;
}

上記では、インデントがバラバラなために、CSS が読みづらくなっています。

改善案

.block {
  background-color: #FFF;
  color: red;
  margin: 80px;
  width: 800px;
}

改善案では、インデントを半角2に揃えたところ、CSS が読みやすくなりました。

インデント幅については、個人の環境に合わせてください。
インデントが半角2が良いか、タブが良いか、などは使用されている言語によって異なると思います。普段使用されている環境と揃えると使いやすいです。

CSS のプロパティをまとめる

CSS のプロパティをまとめて書くことができる場合は、まとめて書きます。

改善余地あり

.cell {
  margin-top: 112px;
  margin-right: 39px;
  margin-bottom: 0;
  margin-left: 0;
  padding-top: 26px;
  padding-right: 0;
  padding-bottom: 84px;
  padding-left: 0;
}

改善案

.cell {
  margin: 112px 39px 0 0;
  padding: 26px 0 84px;
}

改善案では、8行あった CSS プロパティが2行になりました。CSS の記述量を減らして、見やすくなっています。

font や background や border など、まとめて書くことができる CSS プロパティでは、CSS プロパティをまとめて書くようにします。

色の16進トリプレット表記は可能なら3桁表記に

色の指定が3桁表記可能ならば短縮します。

改善余地あり

.modal {color: #000000;}
.content {color: #33bb00;}

改善案

.modal {color: #000;}
.content {color: #3b0;}

短く書いたほうが、見通しがよく容量を少なくすることが可能です。

CSS のネストは孫まで

セレクタのネストは孫までにします。

親 > 子 > 孫

深いネストを避けることにより、CSS の継承がわかりやすくなり可読性を保つことができます。

Sass や Less でネストが簡単に書けるようになった昨今、ムダなネストにより CSS のメンテナンス性が低下する場合があります。過剰なネストを避けることで、CSS のクラスが探しやすくなり、メンテナンス性を保つことができます。

そもそも当記事のように BEM のルールで命名をしている場合、あまりネストする必要はありません。

次に、CSS のレンダリング速度について述べますが、ネストを減らせば可読性が良くなり、レンダリング速度にも良い効果があります。

CSS のレンダリング速度

私はレンダリング速度の良い CSS を書くことは、メンテナンス性の良い CSS を書くことに繋がると考えています。そのような視点で、CSS のレンダリング速度に関する知識を押さえることは意味があります。

CSS は、書き方によってレンダリング速度が変わります。もちろんレンダリング速度が早いコードが望ましいです。

しかし、 CSS の書き方によりレンダリング速度へ影響する差はほとんど存在しないか、存在してもごく僅かです。 CSS はもっともパフォーマンスが良い書き方と、もっとも悪い書き方を比較しても、レンダリング速度に0.1秒程度しか差がでません。

当ページの記法や BEM や SmaCSS などに従って書いていれば、パフォーマンスに影響する割合は無視できるほど十分に軽微になります。

そのため、CSS のレンダリング速度を理由に、最適化にコストをかけすぎる必要はありません。

参考として以下の記事を挙げます。

CSS セレクタを最適化するために時間を費やすのは価値のあることだとは思わない。もし、明日起きて世界中のサイトの CSS セレクタが奇跡的に最適化されていたのなら、私は遠くに行ってこう叫びたい。『誰も気づいてないですやん！！』
https://t32k.me/mol/log/impact-of-css-selector/

CSS のレンダリング速度にまつわる影響は軽微だということです。この点は忘れないでください。

CSS のレンダリング速度を考える場合、まずはブラウザの基本的な挙動を知る必要があります。

ブラウザは CSS を右から解釈する

ブラウザは CSS を右から左へ読みに行きます。一般的に CSS を解釈する場合は左から右に解釈すると思いますが、ブラウザは右からになります。

次に、レンダリング速度を比較するために2つの CSS を用意して比較してみます。

例：レンダリング速度を比較するための２つの CSS

HTML

<div class="modal-content">
  <div class="modal-body">
    <p class="modal-text">One fine body</p>
  </div>
</div>

CSSその1

.modal-content .modal-body p { ... }

CSSその2

.modal-text { ... }

上記、「CSS その1」と「CSS その2」いずれも、One fine body という p タグで囲まれたテキストに対し同様のスタイルを指定しているとします。

全く同じスタイルを表現できる「CSS その1」と「CSS その2」は、どちらが高速に動作するのでしょうか。

セレクタのマッチ数を減らすと高速に動作する

「CSS その1」の場合、ブラウザはページ内の全ての p タグを最初に評価し、次に .modal-body、その次に .modal-content を解釈します。

「 CSS その2」の場合、ブラウザは .modal-text を解釈します。

ページ内には、p タグが100個、.modal-body が10個、.modal-content が10個、.modal-text が10個存在するとします。

「CSS その1」では 100 + 10 + 10 = 120回の判定が行われます。
「CSS その2」では 10回の判定が行われます。

比較すると10回の方が高速

速い : 10回
遅い : 120回

この場合、判定数の少ない「CSS その2」の記述方法が、「CSS その1」よりも高速にレンダリングされます。

これはあくまでも例ですが、上記の高速な 「CSS その2」 と低速な 「CSS その1」 を比較すると、低速な CSS はネストが深く、HTML エレメントにスタイルを書いています。

当記事で紹介したメンテナンスコストが上がるアンチパターンがいくつも挙げています。いずれもの場合もメンテナンスコストが低そうなパターンは、アンチパターンよりも高速な CSS であると気づいた方もいるでしょう。

ベンダープレフィックス

ベンダープレフィックスは各ブラウザごとの草案段階の先行実装や、独自拡張機能であることを判別するための識別子のことです。

ベンダープレフィックスの例

.bdr10 {
  border-radius: 10px;
    -moz-border-radius: 10px; /* Firefox向け */
    -webkit-border-radius: 10px; /* Google Chrome、Safari向け */
    -o-border-radius: 10px; /* Opera向け */
    -ms-border-radius: 10px; /* Internet Explorer向け */
}

ベンダープレフィックスにはメリットとデメリットがあります。メリットとデメリットを理解して利用してください。

プロジェクトでどうしても必要な場合は、ベンダープレフィックスを記述すると良いという考えです。私は自身はなるべくベンダープレフィックスを記述したくありません。

ベンダープレフィックスのメリット

ベンダープレフィックス対応のブラウザで、CSS の最新機能を反映できます。

ベンダープレフィックスのデメリット

ベンダープレフィックスは、CSS の仕様が固まれば、不要になり廃止される場合があります。その場合、CSS ファイルの中に不要なコードが残り、CSS ファイルを肥大化させる可能性があります。

コメント

わかりやすいコメント、運用コストが低いコメントとは何なのかを考えます。

単行コメントを使う

CSS メタ言語の Sass や Less を利用している場合、// が１行コメントとして利用できます。単行コメントを使用して、// と1行ずつコメントにしたほうがメンテしやすいです。

CSS のデフォルトで用意されている、コメント記述方法は、コメント領域が重複する和集合のような記述に適していません。

使用できないコメント例

/*
/*
デフォルトコメントでは入れ子にできない
*/
*/

1行コメントを複数行コメントで囲った例

// コメント
//
/*
// コメントエリアが入れ子になっている
*/

CSS のデフォルトコメントは入れ子にすることができません。
一方で、単行コメントでコーディングしておけば、まとめてコメントエリアにするメンテナンスが可能です。

JavaScript からアクセスする ID とクラス

JavaScript から ID もしくはクラスを利用する場合は、ブロック名の前に js- をつけます。

js- がついたクラスは CSS のファイルには記述せず、デザインのスタイルをあてないようにします。これはスクリプトとデザインで使用されているクラスを明確に分けるためです。

js-で始まるクラス

<div class="js-open-comment comment-area">
  JSで操作したい内容など
</div>

上記では .js-open-comment と .comment-area というクラスがついています。デザインを編集したい場合は、 .js- がついていない .comment-area を編集すればいいことがわかります。また、JavaScript を変更する場合にも、 .js-open-comment クラスのみがスクリプトに影響していることがわかります。.js- というプレフィックスでわかりやすさが向上しているのです。

js- のプレフィックスを付ける場合は、クラスでなく ID を用いてもいいかもしれません。例えば jQuery はクラスよりも ID へのアクセスが速いそうです。

近年は jQuery ではなく JavaScript のフレームワークを使用するケースが増えています。例えば ReactJS や AngularJS などですね。フレームワークを使用する場合、ID やクラスを JavaScript から利用する機会は減少します。

フレームワークを利用することによって、ロジックとデザインの分離がより容易になります。積極的にフレームワークの導入を検討してください。

ID にスタイルをあてない

一般的に、ID に CSS を書かないほうが良いと言われています。

IDがあるHTML

<div id="main-contents">
    <h1>タイトル</h1>
</div>

IDを含むスタイル

#main-contents h1 {
    border-bottom: 1px solid #000;
}

このように ID で指定した CSS にはよく遭遇するはずです。
よくあるこのスタイルは何が問題になるのでしょうか。

HTML と CSS の基本記述の項目から読み返していただけると、なぜスタイルをクラスにあてたほうが良いのかわかるかもしれません。ID にスタイルをあてない理由は、クラスにスタイルをあてる理由と基本的には同様です。

ID はページ内で一つしか使用できない

ID は1つのページで1度しか使用できないというルールがあります。

ページ内で1度しか使用できないスタイルは、複数のページで使用するシーンに適していません。ID にスタイルを書くことは、結果的に1ページでしか利用できない再利用性が低い CSS を生成することになります。再利用性の観点から ID に CSS を書くのはやめたほうがいいです。

ID は詳細度の計算を複雑にする

ID 経由で多重継承した CSS スタイルの継承は、複雑で難易度が高いと感じています。

よくあるケースとして、クラスよりもIDのほうが詳細度が強いという理由でのみ、ID に CSS が書かれている現場があります。そのような書き方をしている CSS は、既にメンテナンスと再利用の観点からは失敗です。

もし、あなたが CSS の詳細度を気にして計算している場合、その CSS は複雑化しはじめています。つまり、既にメンテナンスコストが肥大化傾向にある CSS になっています。

なにしろ、ID に CSS を記述せず、クラスだけで CSS を書き、ネストを適切に保てば詳細度の計算は不要になるのですから。

ここで、ID にスタイルをあててメンテしにくくなった CSS のケースを挙げてみます。

改善余地あり

#box-area ul > #chart div#chart-item {
  color: black;
}

上記のようにIDを多重にネストしたスタイルはメンテ難易度が高いです。

例えば、#chart-item 内にある p セレクタの文字色を赤に変更したくなった時、あなたはどのように指定しますか？

すぐに詳細度が計算できないため、仕方なく ID に書かれた CSS をコピーして、ネストを深くして対応しているのではないでしょうか。

改善余地のあるスタイルを追加

#box-area ul > #chart div#chart-item p {
  color: red;
}

わかりにくく、探しにくく、再利用しにくいスタイルを追加しました。こうなるとまさに泥沼です。

この状況は、そもそも ID にスタイルを書いたのが間違いの始まりです。

このような CSS を書くはずは無いと思うかもしれません。しかし、ID ばかりにスタイルを指定した CSS が使用されている現場はかなり多いはずです。

インラインスタイルは使用不可

基本的にはインラインスタイルは使わないようにします。

インラインスタイルは記述したタグに対して基本的に一度しか使用できません。つまり、メンテナンス性と再利用性の観点から使用しないほうが好ましいと考えます。

PageSpeed Insightsの指摘

GoogleのPageSpeed Insightsでは、 CSS 属性をインライン化しないように指摘があります。

コードの不要な重複につながる場合があるため、HTML 要素に CSS 属性（< p style=...> など）をインライン化するのはできるだけ避けてください。また、 HTML 要素への CSS のインライン化は、Content Security Policy（CSP）によってデフォルトでブロックされます。

!important は使用可

!important は基本的に使用しないようにします。一般的に !important は使用しないほうが良いと言われています。なぜなら、!important を安易に使用し始めると CSS の中身が !important だらけになってしまうからです。

ただ、!important は無理して使わないようにするのではなく、どうしてもやむを得ない場合のみ使用するように考えています。

例えば、 CSS のフレームワークを利用している場合、多重に継承されているスタイルを打ち消さなければならない場合があるかもしれません。そのような場合は詳細度を計算するよりも !important を使用したほうが簡単です。

もし自分の CSS に !important を記述したくなった場合、既に CSS の詳細度が複雑になっている可能性があります。!important を使用する前に、 CSS を捨てシンプルにすることでデザインを実現できないかを確認してください。

汎用クラスは使用可

自作の汎用クラスは基本的には使用しません。

Web 制作屋さんが作った CSS を見ると大抵汎用クラスが使用されています。

ありがちな汎用クラス

.p-0 !important /* padding : 0; のクラス */
.mb10 !important /* margin-bottom : 10px; のクラス */

上記のような汎用クラスを多く使用したデザイン定義は、インラインスタイルばかり使用してデザインを定義している状態と同様です。

自作汎用クラスを使用しはじめると、HTML が汎用クラスだらけになり、HTML の可読性が下がります。汎用クラスはなるべく定義しないようにします。

汎用クラスを使いたがる人

汎用クラスを急に使い出す人がいたらその人は疲れてきた可能性があります。
疲れた人には休暇をとってもらいましょう。

仮に、汎用クラスを自作して命名する場合は、Emmetベースのクラス名にすると、わかりやすくなります。

使用する汎用クラスはフレームワークのクラスのみ

Bootstrap などのフレームワークのクラスを、汎用クラスとして利用してください。

大抵の場合、 CSS フレームワークのクラスは BEM で記述されていないと思います。
本ルールのように自作クラスを BEM のルールで書くようにしておくと、自作クラスと汎用クラスを明確にわけることが可能です。

詳細度は計算しない

HTML と CSS において詳細度の計算はまったく意味が無いと思います。詳細度について深く知らなくても十分 HTML と CSS を扱えるからです。

当記事で紹介しているように、BEM でコーディングして、ネストを３以下に守っていれば、詳細度を気にする場面は訪れません。

既存のソースを引き継いだために、やむを得ず詳細度の大小がわからなくなった際には、!important を付けて解消すると良いです。!important の利用は基本的には好ましくはありませんが、すぐに書き直せない場合は構わないと思います。

詳細度の計算が必要になった場合は、 HTML と CSS がメンテナンスしにくなっている箇所を確認する機会にすると良いです。詳細度は計算したら負けなのです。

最後に、この記事を書いた理由

私は Rails などフレームワークのビューや WordPress のテーマを書く機会があります。そんな中で経験した学びが3点あります。

• 既存のコードを再利用できる場合は時間がかからない。
• 自分あるいは他の人が書いた HTML と CSS を、読んだり、探したり、打ち消したり上書きする場合は時間がかかっている。
• HTML や CSS をどうやって書くか考えるのに時間がかかっている。実際のコーディングは短時間で完了する。

再利用できる HTML と CSS を重複コーディングするのは非効率です。HTML や CSS を探したり上書きに時間をかける工程は、少なければ少ないほど好ましいです。悩む時間はなるべく少なくしたいです。

開発速度とメンテナンス性など、トータルで見た時に、時間がかからない HTML と CSS は品質が高く、時間がかかる HTML と CSS は品質が低いと考えます。

上記のような点を考慮した結果、人間が品質の高い HTML や CSS コーディングを行うには、決まった規約でコーディングを行い、コーディングのフローを仕組み化していくことが望ましいと考えました。

おまけ：コーディング作業環境の効率化

HTML と CSS のコーディングを効率化する

コーディング環境を効率化しましょう。エディタやツールを使うことで、単純に HTML & CSS コーディングを行うよりも時間を節約できます。

コーディング用のエディタを使う

私が最初に HTML を書いた時は Windows のメモ帳を使っていました。
しかし、Dreamweaver や SublimeText など、リッチなエディタを使用すれば、ずっと効率的に HTML や CSS をコーディングすることが可能です。

過去に Dreamweaver、秀丸や Vim、IntelliJ IDEA、SubmlimeText、Atom を経て、いまでは Visual Studio Code というエディタを利用しています。これらのエディタで emmet などの入力補完を使用すれば、コーディングにかかるコストをかなり省力化できます。

メタ言語（ CSS プリプロセッサ）を使う

CSS メタ言語（ CSS プリプロセッサ）の使用はコーディング作業を楽にします。例えば Sass を使用すれば CSS の重複するクラスのコーディングが不要になり、コーディング量や負担が大幅に下がります。

CSS をチェックするツール

CSS がちゃんと書かれているかを目視でチェックするのは無駄なコストです。チェックツールを使用すると簡単に CSS をチェックできます。

• https://csslint.net/

lint で検索するとエディタに導入できるようなものもあります。具体的には挙げませんが、色々探してみてください。

参考

自分の過去のメモや以下のページを参考にしました

• Google HTML / CSS Style Guide
• https://google.github.io/styleguide/htmlcssguide.html
• MindBEMding
• https://gist.github.com/juno/6182957
• HTML と CSS クラスでよく使う命名について
• https://qiita.com/pugiemonn/items/eaa597b79fe59a1f1506
• CSS の配信を最適化する
• https://developers.google.com/speed/docs/insights/OptimizeCSSDelivery?hl=ja
• CSS セレクタのパフォーマンスへの影響
• https://t32k.me/mol/log/impact-of-css-selector/
• キーワードは「CARE」！実践的なフロントエンドエンジニアを目指せ！─Frontrend Conference the Final基調講演レポート
• https://html5experts.jp/shumpei-shiraishi/13130/