CSSの設計について。

CSSは単純に書くだけであれば簡単ですが、運用していくと扱いが非常に難しいです。

とくに、サーバーサイドあがりのフロントエンジニアにはCSS設計って何をどうしたらいいのさ？ってことになりがちです。
なので、今回はCSSの設計を考えさせられる題材にしました。

よりよいCSSとは？

Philip Walton氏のブログ記事の引用ですが、よりよいCSSは下記のような点があげられます。
参考：http://urx.nu/bdMt

・よりよいCSS

予測しやすい
⇒ ルールが期待通りに振る舞うこと。

再利用しやすい
⇒ ルールが抽象的で、問題を書き直す必要がなく、既存のパーツから新しいコンポーネントを速く作れるということ。

保守しやすい
⇒ 新しいコンポーネントと機能が追加・更新されるとき、既存のCSSのリファクタリングを必要としない。

拡張しやすい
⇒ CSS設計の学習コストが低く、安易に管理できること。


・よくないCSS

親に基づいてコンポーネントを修正する
⇒ クラス定義を一旦終えてから、特定のユースケースのためだけにそのクラス定義を変更するようなこと。再利用性・保守性がない。

過剰に複雑なセレクタ
⇒ HTMLが今後まったく変わらないのであればメリットはありえるが、そんなケースはほぼない。再利用性・予測ができない。

過剰に一般的なクラス名
⇒ 「.name」「.title」などのクラスでは、何の名前なのか・タイトルなのか、予測しづらい。そして、一般的なクラス名はコンポーネント内で重複しやすい。

1つのルールで過剰にスタイルする
⇒ 1つのルールで全てを指定する場合、見た目は再利用可能だが、配置に関しては再利用しづらい。

言ってることはリーダブルコードなどに載っているようなことと大体一緒。

コンポーネント設計の概念的なもの

CSSにも設計について色々な概念があります。
いくつか紹介していきます。

• OOCSS(Object Oriented CSS)

オブジェクト指向のスタイルシートのこと。
構造とスキンを分離してクラス定義して、それらを組み合わせてスタイルを定義するという方法。

詳細は下記の記事が分かりやすかったです。
難しいOOCSS（オブジェクト指向CSS）の設計： http://hijiriworld.com/web/oocss-design/

クラス数が増えるし、どこまで細かく分けて実装していくかなどに統制とれるようにしなきゃならないし、
セマンティックな人とも戦いが起こるかもしれない。
OOCSSとSass： http://takazudo.github.io/blog/entry/2012-12-10-oocsssass.html

大規模サイトとかになると、パフォーマンスに影響でてくるボリュームになるかも。

• BEM(ベム)

Block、Element、Modifierの略称で、CSSの構成をこの3つにカテゴライズする。
そして、そのカテゴリにそったクラス名をつける方法。

Block： 各パーツ(ヘッダー・フッター・商品説明・検索ボックスなど)のルートとなる要素。
⇒ 「Block名」のようなクラス名となる。

Element： Blockの構成要素で、クラス名には必ずBlock名を含める。
⇒ 「Block名__Element名」のようなクラス名となる。

Modifier： 基本のレイアウトは一緒だが、見た目や動きをつけたい場合に使う。そして、名前(name)と値(value)を使い、複数パターンの状態を作る。
⇒ 「Block名_name_value」のようなクラス名をつける。

こちらの記事が分かりやすかったです。
BEMによるフロントエンドの設計 基本概念とルール： https://app.codegrid.net/entry/bem-basic-1

クラス名はかなり長くなりそう。

• SMACSS(スマックス)

Scalable and Modular Architecture for CSSの略称。
基本的な概念はBEMと同じようなもので、CSSの構成を5つのカテゴリに分ける。
(ベース・レイアウト・モジュール・状態・テーマ)

ベース： サイト全体で要素そのもののデフォルトスタイルを定義する。また、CSSリセットもベースルールに含まれる。
⇒ IDやクラスは使わず、要素自体にスタイルをあてる。

レイアウト： ヘッダー・フッター・コンテンツエリア・サイドバーなどの構成の大枠を作る要素へのルール。IDを使って指定するのもあり。
ページのエリア分け。
⇒ ひと目で意味がわかるように、クラス名の接頭辞に「l-*」又は「layout-*」をつけることを推奨している。

モジュール： レイアウト以外の構成要素は大体モジュールとして捉える。(ボタン・見出しなど)
⇒ 命名規則は特にないが、親モジュール名を接頭辞につけたり、「m-*」や「module-*」などをつけてもよい。

状態： モジュールの状態を表すルール。is-状態というカタチでクラス名を指定する。
⇒ クラス名の接頭辞に「is-*」をつける。（is-toggle-activeとか

テーマ： テーマを切り替える機能が必要な場合のみ使うカテゴリ。body要素に対してtheme-sky-blueみたいなクラスを付与して切り替える、とか。
⇒ クラス名の接頭辞に「theme-*」をつける。

カテゴライズが多いが、案件内でキチッと決まってたらとても読みやすそうだし、作る際にも名前に悩まなくなりそう。
個人的にはBEMのような長いクラス名より好ましい。

こちらの記事に詳しく書かれていました。
SMACSSによるCSSの設計 ベースとレイアウト： https://app.codegrid.net/entry/smacss-1
SMACSS 読んだ： http://chroma.hatenablog.com/entry/2013/07/22/120818
今必要なCSSアーキテクチャ： http://www.slideshare.net/MayuKimura/css-25547100

• その他

MCSS(Multilayer CSS)
BEMとOOCSSの原理を基にした構成らしい。
Multilayer CSS： http://operatino.github.io/MCSS/ja/

FLOCSS(フロックス)
OOCSSやSMACSS、BEM、SuitCSSの原理を基にした構成らしい。
MCSSのレイヤー構成にも大きな影響を受けている。
FLOCSS： https://github.com/hiloki/flocss

他にも、色々ある。

まとめ

調べてて思ったのは、これらの設計思想を全部理解するのは辛いので、
これらを元にしながら案件独自のルールに落としこむのが良さそう。

運用中などに破綻して、ベースから書き換えなきゃいけない(SASSを使ってる場合だと修正は一瞬で済んでもCSS差分は膨大)とかにならないよう、はじめにしっかりと決めたい部分です。

以上！