はじめに

それでもCSSは破綻する。書くこと自体はとても簡単なCSSですが、その一方で、CSSの設計が簡単に破綻してしまいます。破綻しないためにCSSの設計手法と書き方のノウハウをご紹介できればと思います。
以前の記事とかぶるとこも結構あるのですが、全体的にまとまっているので特に初心者〜中級者の方に見てもらえたら嬉しいです。

CSSは簡単!CSSできる!って言っている人はだいたいうそ

これは極端な言い方ですが、今まであったデザイナーでCSSできると言った人で本当にできる人あまりいないです。
どちらかというとCSSは難しいと言った人の方ができる方が多いです。

CSSを書くこと自体は簡単

CSSが簡単だと思われてしまう要因の一つがCSSを書くこと自体は言語としてはかなり簡単な部類に入ります。

p{
  color: #f00;
}

このようなコードをツラツラ書いていけばHTMLに対してスタイルをつけられますよね。
書き方としてはごくごくシンプルです。シンプルであるがゆえに管理するのが難しいのです。

前置きはこれくらいにしてここから先はCSSがいかに難しいことについて触れていきたいと思います。

CSSは破綻しやすい

何が難しいかと言うと一つだけです。そう「破綻」しやすいんです。

では、「**CSSの破綻**」とはなんでしょう？

例えば
「新しくスタイルを書いたのに適用されない」とか
「!importantが乱用されている」とか
が挙げられます。

破綻というとなかなか難しいですが、複数人で複数人で同じCSSファイルを編集していると起こりやすいです。
具体的には・・・

同じようなコードが複数箇所ある場合がある

似たようなコードもしくは同じコードが重複してしまっている状態。

セレクタ名が被りやすい

セレクタ名が同じものが乱立している状態。

スタイルの詳細度問題

上記を解消するために詳細度を深くしてなんとかスタイルを割り当てている状態だったり「!important」を乱用している状態。

上記のようなことが起きているようなCSSのコードは完全に破綻しています。

良いCSSのコードとは

では**「破綻のしない」良いCSSのコード**ってどんなのなんでしょう。よく言われるのが・・・

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

予測しやすい

セレクタ名には.aとか.cなど自分だけがわかるものは基本NGです。あとは、クラスセレクタに日付が書いてあったり、「new」とか書いてあるのが見かけることがあります。もうこれは末期ですね。おそらく破綻してます。
例えばタイトルならば.title、バナーを配置する場所なら.banner-areaなどクラス名を見ただけでなんとなくどんな使い方がされているかわかるものがいいです。

再利用しやすい

サイト内のどこに配置しても大丈夫なように作られている方がいいでしょう

保守しやすい

詳細度と関連してくるのですが、詳細度を深くしすぎるとのちのちスタイルの上書きする際に困ります。

拡張しやすい

例えばタイトルであれば、文字の大きさの違うパターンや色違いパターンなどが作りやすい方がいいです。

CSSを書く上で気をつけるべきこと

ポイントは5つあります。一つずつご紹介します。

CSSのプロパティはまとめられるものはまとめる

まとめられるものがあるならばまとめた方がいいですね。ファイルサイズ節約にもなります。
運用の時に付け足す時もそっとまとめてあげるといいですよね！！

//Bad
h1 {
  padding-bottom: 2em;
  padding-left: 1em;
  padding-right: 1em;
  padding-top: 0;
}

// Good
h1 {
  padding: 0 1em 2em;
}

意味のないセレクタ、スタイルは作らない

下記のコードは実際に僕が出くわしたコードです。見た時正直びっくりしました。以前担当していた方が書いたんでしょうけど、同じスタイルじゃん・・・。なんでこうなったかは理解に苦しむんですが、これもクラス一個で各ページ使い回せばいいだけですよね。

// Bad
.regist .error p{
  color: #f73265;
  font-weight: bold;
  font-size: 13px;
  margin: 8px 0;
  padding-bottom: 3px;
  border-bottom: 2px solid #f73265;
}

.memberinfo #main .error-message{
  color: #f73265;
  font-weight: bold;
  font-size: 13px;
  margin: 8px 0;
  padding-bottom: 3px;
  border-bottom: 2px solid #f73265;
}

// Good
.error-message{
  color: #f73265;
  font-weight: bold;
  font-size: 13px;
  margin: 8px 0;
  padding-bottom: 3px;
  border-bottom: 2px solid #f73265;
}

マークアップが変わっても問題のないセレクタにする

idセレクタ、クラスセレクタ、タイプセレクタと異なるセレクタが混在していると、マークアップが変わった時に対応ができません。

// Bad
#hoge .menu ul{}
#hoge .menu ul li{}

// Good
.menu{}
.menu__item{}

こちらはBEMという書き方をしていますが、後ほど詳しくご紹介します。

余計なタイプセレクタは使わない

下記の「Bad」のやり方はわかりやすいっちゃわかりやすいんですが、再利用性に欠けます。というのもh1にしか使えないので、たとえば、マークアップ的にh2の方が適切の場合はスタイルを適用できないですね。

// Bad
h1.title{}


// Good
.title{}

親要素のセレクタに依存したセレクタにしない

cssのテクニックとして「body」タグにクラスをつけてコンテンツのスタイルをページごとに変更したりします。でもこれって「body」タグにクラスに依存しすぎてしまっていて再利用しづらいし、拡張もしにくいですよね。

たとえば、デフォルトのヘッダーとメニュー詳細ページでヘッダーのスタイルを変更したい場合、以下のような書き方をします。でもこれって、運用していくなかで新しくページを追加して（LPとかね）詳細ページと同じヘッダーでって場合どうしますか？

パターンとしてはdetailと同じスタイルをLP用につくるか、LPのbodyにdetailを付与ですよね？
後者の場合ってめちゃくちゃ気持ち悪いですよね。detailページでもないのにbodyにdetailって・・・

// Bad
.header{
  width: 100%;
  background: #000;
}
.detail .header{
  width: 100%;
  background: #fff;
}

.lp .header{
  width: 100%;
  background: #fff;
}

// or
.detail .header, .lp .header{
  width: 100%;
  background: #fff;
}

このパターンでCSSを書くとページが増える度にセレクタを書き加えなければいけませんね。
これをBEMでセレクタを書くとめっちゃわかりやすくなります！！ポイントはページ単位で切り分けないでプロパティごとに切り分けた方がいいかなと思います。

// Good
.header{
  width: 100%;
  background: #000;
}
.header--bg-white{
  background: #fff;
}

それでもCSSは破綻する

これまでのことを気をつけても更新作業などをしていればほぼ100%破綻します
次に紹介するのは**CSSの設計**です。自由に書けるCSSだからこそルールを設けてみんなで守りましょうというものです。

CSS設計の手法

• SMACSS
• OOCSS
• FLOCSS
• BEM

実はCSS設計の手法ってたくさん存在しています。それぞれ特徴があったりしますが基本的な考え方としては**破綻のしにくいCSSのコード**を書きましょうというのは変わりません。
自分のやりやすいものやそのWEBサイトにあったものを選ぶのがいいと思います。今回は「**FLOCSS**と**BEM**」をご紹介します。

FLOCSSとBEMのCSS設計

FLOCSSというのは、日本人が考えたCSSの設計手法です。実は、「Web制作者のためのCSS設計の教科書 モダンWeb開発に欠かせない「修正しやすいCSS」の設計手法」という本を書いた谷さんという方が考えたものです。

BEMは、セレクタの書き方の考え方です。賛否両論ありますが、HTMLのタグを見ただけでどんなスタイルかわかりやすいというメリットがあります。
デメリットとしてはセレクタが長くなりがちです。

ディレクトリ構成

まずはFLOCSSの基本としてサイトのCSSディレクトリの中身を分けます。これで、どこにどんなスタイルを書くかわかりやすくなりますね。
ちなみに、今回はSassを使っている想定にしています。これはなぜかと言うと`import`する際にCSSの場合

@import url('foundation/base.css');
@import url('foundation/reset.css');
・・・

と言うように書くのですが、このimport文だとサイトの読み込みに時間がかかってしまうんですね。そこでSassを使うと実際にページに読み込まれる時にはいimportし終わっていて一つにまとめられたCSSファイルが生成することができます。importの書き方は

@import "foundation/base";
@import "foundation/header";
・・・

と言うようにできます。Sassを使う方がメリットもたくさんあるので興味のある方はぜひ使ってみてください。

横道にずれてしまいましたが、ディレクトリの構成は以下のようになります。

├── foundation
│  └── base.scss
│  └── reset.scss
├── layout
├── object
│  ├── component
│  ├── project
│  └── utility
└── app.css

foundationとは

ここはbase.scssやreset.scssなどサイト全体の下地になる部分を書きます。

layoutとは

ここはサイトの基本レイアウトを書く場所です。例えばheaderやfooterなど

objectとは

ここではサイト全体で再利用性の高いスタイルを書きます。

component

componentは再利用性の高いパーツを書く場所です。特徴としてはどんなサイトでも大概あるパーツを書くことが多いです。
例えば、ボタンスタイル、タブスタイル、見出しスタイルなど

project

projectも再利用性の高いパーツを書く場所なんですが、componentととの違いは、このサイト特有のパーツの場合はここに書きます。
例えば、グラフスタイル、ドロップゾーンなど

utility

ここはいつでもどこでも使えるスタイルです。基本的には1セレクタに1プロパティになることが多いです。

.u-mb-8{
 margin-bottom: 8px;
}
.u-pt-16 {
 padding-top: 16px;
}

app.scss

app.scss内に各ファイルをimportします。

@import "foundation/base";
@import "foundation/header";
・・・

接頭辞

FLOCSSではなんの属性なのかHTMLのコードを見ただけですぐにわかるように接頭辞をつけることを義務付けしています。

どこのディレクトリにあるか表す接頭辞

.l- // layout
.c- // component
.p- // project
.u- // utility

状態を表す接頭辞

こちらはjQueryなどと併用する時によく使われます。例えばボタンを押すと出てくるUIなどは.is-showなどのクラスセレクタをつけたりします。
.js-はjs(jQuery)と関わっているのか表す接頭辞です。

.is-
.js-

これはJSで動くなど何かしら操作したときなどにセレクタで呼び出しますが、その際はスタイルで定義されたセレクタを使うのではなく必ず「.js-hoge」などで行うことを義務付けします。そうすることで文書構造、スタイル、スクリプトを完全に分離することができてHTMLを見るだけで何が行われているのか、残さなければいけないセレクタなのかわかりやすくなります。

<div class="c-drawer">
 <button class="c-drawer__btn js-drawer-btn">開く</div>
 <div class="c-drawer__content is-open">
  // 内容
 </div>
</div>

セレクタについて

基本的にクラスを使う

idセレクタとクラスセレクタが基本的にはよく使われるセレクタですが、idセレクタはあまり使わない方がいいです。実はidセレクタには問題点があります。

idセレクタの問題点

• 詳細度が強すぎる
• 1ページに一回しか使えない

というのも詳細度と関連してくるのですが、基本的にidセレクタは詳細度がかなり強いです。なので、スタイルを上書きしなければいけない場合にどうしてもそれ以上の詳細度にしなければいけません。さらに、1ページに一回しか使えないので、再利用性にかけます。

書き方はBEM

先ほどのdrawerのコードであまり見かけないセレクタの書き方がありました。これが実はBEMの書き方です。
そしてBEMのセレクタの書き方には3つの要素でできています。その頭文字をとってBEMと言います。

Block

これはdrawerなどのパーツなどの塊を表します。FLOCSSではこのBlockごとにCSSのファイルを書いていくのがいいでしょう。

Element

これはBlock内に存在する要素を表します。drawerで言えばボタンやコンテンツですね。

Modifier

これは状態を表します。例えば、背景の色が違うパターンなど
注意！.is-や.js-とは使い方が違います。

.c-drawer--right {

}
.c-drawer--left {

}

BlockとElementのつなぎ方

セレクタでBlockとElementのつなぐ方法はアンダースコアを二つつけます。

Block or ElementとModifierを繋ぐ

Modifierの前にハイフンを二つつけます。

BEMの失敗パターン

先ほどもご紹介したようにBEMのデメリットはセレクタが長くなりすぎます。

<ul class="menu">
  <li class="menu__item">
    <a class="menu__item__content" href="#">
      <h3 class="menu__item__content__title menu__item__content__title--red">タイトル</h3>
      <div class="menu__item__content__thumb"><img src="hoge.png" alt=""></div>
      <div class="menu__item__content__meta">
        <span class="menu__item__content__meta__date">2015/12/31</span>
      </div>
    </a>
  </li>
</ul>

.menu{}
.menu__item{}
.menu__item__content{}
.menu__item__content__thumb{}
.menu__item__content__title{}
.menu__item__content__title--red{}
.menu__item__content__meta{}
.menu__item__content__meta__date{}

こういったケースが頻発するのでcomponentを小分けしていくといいです。そうすると小さい単位のcomponentごとに各componentを組み合わせて使いまわすことが可能になります。

// menu.css
.menu{}
.menu__item{}

// media.css
.media{}
.media__title{}
.media__title--red{}
.media__thumb{}

// meta.css
.meta{}
.meta__date{}

<ul class="menu">
  <li class="menu__item">
    <a class="media" href="#">
      <h3 class="media__title media__title--red">タイトル</h3>
      <div class="media__thumb"><img src="hoge.png" alt=""></div>
      <div class="meta">
        <span class="meta__date">2015/12/31</span>
      </div>
    </a>
  </li>
</ul>

それでもCSSは破綻する

ここまでやっても**CSSは破綻**します。そうですねこれでも80%以上の確率で破綻します。複数人いる場合には特に！！

ガイドライン

そのサイトやサービスに置けるルールを記します。
記載する内容は作る人や企業によってまちまちですが、基本的なものとしては

• 対応ブラウザについて
• クラスセレクタの書き方(BEMであればセパレートはアンダースコアなのかとか)
• 禁止事項など

スタイルガイド

よく使われるcomponentに関してはコードをまとめておくといいです。

下記のは僕が作ったフレームワークのものですが、なんとなくの雰囲気はつかめるかなと思います。
[Document](http://takumi0901.github.io/flanky/)

ここまでやってやっと破綻のしにくいCSSになる

あくまで「しにくい」です。せっかく作ったガイドラインを無視したりする人がいれば「破綻」します。大体の企業では何かサービス作るにあたってあらかじめガイドラインが設けられていることが多いです。なので、そのサービスに途中から参加する場合などはガイドラインを読み込み、実際のCSSコードを追って理解を深めるのがいいと思います。