CSSの基本はとてもシンプル。

//pタグのテキストカラーを緑に
p {
  color: green;
}

こんなかんじで他の言語よりも直観的にわかることが多く、言語の中では比較的簡単に書けるのがいいですね。
ただ、誰でも比較的簡単に書けるメリットはあるものの、後先考えずに色々と付け足していくと、後になって問題が発生してきます。

問題が起こる原因をいくつかあげてみましょう。

  • スタイルがあちこちいろんなところに書かれてる
  • クラス名が重複している
  • スタイルの詳細度/!importantでの上書き合戦
  • ソース内で違う場所への移動するとデザインが壊れる
    (HTMLの構造に依存しすぎている)

サイトの規模が大きくなればなるほどこういった問題が起こります。

ちょっとした修正がしたいだけなのに、過去に何気なく書いたCSSが原因でうまくいかず、さらにカオスなCSSに…という悲しいことが起こります。

CSSの場合、他の言語と違ってエラーを出さないため、知らず知らずの内にバグを生み出していくというケースが結構多いように思います。

CSSは簡単に書ける一方で、とても壊れやすい言語でもあります。
そこで今回は「CSSの設計」について書いてみようと思います。

その前に良いCSSってなんだろう…?

良いCSSの定義としてGoogleのエンジニアのPhilip Waltonさんがブログであげているのがこの4つです。

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

CSS Architecture — Philip Walto
日本語訳はこちら

以下、サイトから一部引用します。

予測しやすい

ルールが期待通りに振る舞うことを意味する。
ルールを追加・更新したとき、そのルールが意図せずサイトの一部に影響を与えるべきではない

再利用しやすい

既存のパーツから新しいコンポーネントを速くつくることができる

保守しやすい

新しいコンポーネントと機能が追加・更新されるか、再編される必要があるとき、既存のCSSのリファクタリングを必要とすべきではない。

拡張しやすい

ひとりのデベロッパか、大きなエンジニアチームかを問わず、容易に管理できることを意味する。またそのサイトのCSSアーキテクチャに、巨大な学習曲線を必要することなく容易に近づけるという意味でもある。

この他にも

一貫性のあるCSSらしいCSSを書くための原則にも似たようなことが書かれてます。

どんなに多くの人が貢献したとしても、どのコードも一人で書いたようにする。
同意の上のでのスタイルを厳格に守る。
もし悩むようであれば常に現存する共通のパターンを利用する。

なんとなく良いCSSの定義が見えてきたところで、CSS設計にどんなものがあるか見ていこうと思います。

CSSの設計方法色々

CSSの設計は結構色々あります。

それぞれに向き不向きはあるのですが、まずはOOCSS、BEM、SMACSSあたりに注目して勉強していくといいかなと思います。
個別に説明していくと大分長くなるのでざっくりと書いてみます。

OOCSS(オーオーシーエスエス)

img_oocss

Object-oriented CSS

Object Oriented CSSの略。
YahooのNicole Sullivanさんが考案

オブジェクト指向に基づいた設計でそれぞれが独立したスタイルで、色々なところに使いまわせるのが特徴。
同じことを何度も書くことをやめて、再利用しやすいCSSを書こうというもの。
Componentsをレゴに例え、ページはレゴみたいに組み合わせてを作ろうというようなことを言ってます。

“いかにID、class名を少なくして書くか”
そんなことを言われてた時代もありましたが、最近ではメンテナンス性をあげるためにもclassセレクタをたくさん追加し、あちこちで使いまわせる組み方が主流となってきています。

参考サイト
知っておきたいHTMLテンプレート設計法 – OOCSSの基本 | CodeGrid
OOCSS(オブジェクト指向CSS)のススメ | hijiriworld Web

BEM(ベム)

img_bem

BEM. Block, Element, Modifier

ロシアのYandex社さんが考案。
html構造を明確にすることに軸を置いた設計。
厳しい命名規則が特徴的です。

BEMにはBlock、Element、Modifierという3つに分けて考えています。

  • Block
    classで指定。何度も繰り返し使うもの。Blockはどこに移動しても単体で動作するもの。コンポーネントそのものを包括する親要素
  • Element
    Blockに中にある子要素
  • Modifier
    BlockやElementの見た目などが変化した状態

この3つに沿って命名規則をつけていくのが特徴で、
.block__element–modifier
といったクラス名を付けていきます。

一度案件でBEM方式でやったことがあるのですが、この命名ルールにしっくりこなくて少しトラウマになってます…
なので命名ルールだけ自分流にカスタマイズして使うのはありかなと個人的に思います。

参考サイト
BEMによるフロントエンドの設計 – 基本概念とルール | CodeGrid
BEM Advent Calendar 2013 – Adventar

SMACSS(スマックス)

img_smacss

SMACSS – Scalable and Modular Architecture for CSS (日本語)

OOCSSとBEMの流れを見て、Jonathan Snookさん考案。
SMACSSでは要素をBase,Layout,Module,State,Themeの5つに分けて考えています。

  • Base
    サイトのデフォルトスタイル(reset,css や Normalize.cssがこれにあたる)
  • Layout
    サイトレイアウトの枠組み
  • Module
    レイアウトの中にはいるもの
  • State
    状態ルール
  • Theme
    テーマ

この設計に従いSASSファイルをわけて、あとで、まとめて一つにするという手法をとってる人もいます。

参考サイト
SMACSSによるCSSの設計 – ベースとレイアウト | CodeGrid

OOCSSBEMSMACSSの中でどれが一番いいですか…というのはその案件の性質だったり、開発するメンバーにもよるので、その時に応じて使い分けるというのが理想的かなと思います。

スタイルガイド駆動の開発

OOCSSが出たときに’スタイルガイド駆動の開発’ という言葉がでてきました。
コンポーネントを作成する際、まずはスタイルガイドの作成をしていこうという考え方です。
スタイルガイドを作るメリットは色々ありますが、実際作ってみた個人の感想をあげると…

  • 「あれのクラス名なんだっけなー」とか「このサイト、他にどんなクラス作ってたっけな―」ってときにあるときにパッと探せて便利
  • CSSの設計でイケてないところを発見できる。
    (命名規則のルールが崩壊してる、同じデザインなのに他の箇所で再利用ができないクラスの発見など)

といったかんじでしょうか。

作る手間はあるものの、その分、後あと更新作業での作業効率化・品質向上にはつながると思うので、ある程度規模が大きいサイトを作るときには作成するようにしています。

スタイルガイドの形としてはGithubが公開してるオープンソースのCSSフレームワーク[Primer]などがあります。
(「Primer」にはガイドラインも公開されているのでそちらも合わせて読んでみると勉強になります。)

また、スタイルガイドを作るとき便利なジェネレータについてもいくつかあります。

Gruntなどのタスクランナーを使っているのであればKSSかStyledocco
SASSを使ってなくて、RubyとかNode.jsとか環境を整えるのが面倒であればKaleiですかね。

CSSファイルにコメントアウトで記述するだけでページが生成されるのでとても便利です。

初期段階でのCSS設計

CSS設計について学んでいくと、コーディング前のデザイン段階でどうにかしておくようなものでは…
という思いが次第に強くなってきます。

よくある案件のワークフローはこんなかんじでしょうか。
企画 → 設計 → デザイン → マークアップ → 検証確認 → 公開

でも理想のワークフローはこんなかんじ…
企画 → 設計 → プロトタイプ・確認 → デザイン・マークアップ → 修正調整

マークアップにお仕事がくるときは、デザイナーさんがページでデザインを作成し、OKが出たページから順次コーディングを開始するワークフローがとても多いです。

しかし、ある程度規模が大きく、更新頻度が多いサイトになってくると、メンテナンスに強い設計作りは大切になってきます。なので、そういうサイトについてはできるだけ早い段階で案件に関われるのが理想的です。

サイトの構築にあたってはページ単位ではなく、コンポーネント(またはモジュール)単位で設計し、場所依存しない設計にすることで、大分効率的に作業ができるかと思います。

最近ではプロトタイプを作ってからスタートするやり方を取り入れてる人もいます。
動作確認をしつつ、ユーザーが使いやすい形ができてから、細かい部分を作り込んでいく手法です。
今までとはやり方が違うので、マークアップだけでなく、お客さんや、他作業者の理解も必要にはなってきますが、モバイル端末の普及率を考えるとこういったワークフローはどんどん増えてくるのではないかと思います。

最後に…

正直、HTMLとCSSがものすごくカオスなことになっていようが、表のデザインが崩れていなければ、そこまでコーディングには価値を求めない・・・そういう考え方もあるかと思います。
ただ、マークアップエンジニアとしてお仕事をする以上は、
“誰だよこのCSS書いたの!ものすごくわかりづらい上に汎用性がないじゃん!”
と思われるのではなく、
“ひょっとして、こういう組み方にも対応できる…?できた!!!”
という風に、後で触る人になるべくストレスを感じさせない。そんな設計をしていきたいなと思う今日この頃です。そうすれば無駄な残業も減りますしね!

最後になりましたが、Qriptでは現在マークアップエンジニアを募集しています。
HTML・CSS、もしくはJavascriptが好きだという方。
いらっしゃいましたら是非応募ボタンをぽちっとしていただけるとうれしいです。

採用情報についてはこちらをご覧ください。

以上、よろしくお願いします。