はじめに

CSSはとてもシンプル

今「CSSの設計」を改めて考えるのは、なぜでしょうか。CSSの基本はとてもシンプルです。例えば、次のようにHTMLにクラスを付け、そのクラスに対してのスタイル指定をCSSで行うだけです。

<div class="box">
  hoge
</div>

.box {
 color: red;
}

HTMLの要素が入れ子になった場合も、セレクタを増やすだけで対応できます。

<div class="box">
  <div class="inner">
    hoge
  </div>
</div>

.box .inner {
  color: red;
}

こうやって元々の仕組みだけを見ると、CSSはそんなに難しくありません。複雑なパターンになったとしても、基本は前述のやり方ですみます。また、プロパティも多くありますが、他のJavaScriptなどのプログラム言語と比べると、理解はしやすいですし、Dreamweaverなどプロパティ名を補完してくれるツールも数多くあります。

Webサイト制作で起きる「崩れていくCSS」問題

以下に挙げる問題は、サイトの規模が大きくなればなるほど、起きやすくなる問題です。

重複するクラス名

先ほどの例では、box、innerというクラス名を付けていますが、このクラス名が、サイトの別の場所でcolor: redに意図はなく使われていたとしましょう。文字を赤くするつもりもない場所でも、当然、文字が赤くなります。

スタイルが書かれている場所が不明

HTMLとCSSは別の言語なので、ファイルを分けて管理するが多いでしょう。HTMLのページ数も増えると、CSSのファイルの数も多くなってくる場合があります。セレクタも複雑になります。

そうなると、あるHTML要素のスタイルが、どのCSSファイルのどこで指定されているのか、わからなくなることがあるでしょう。

そして使われる「天下の宝刀」

どこに書いてあるのかわからない場合、任意のスタイルを適用する解決方法のひとつは、自分で!importantなどと最強のスタイルを上書きしてしまうことです。例えば、こんな具合に。もちろんこんなことをしてしまっては、このスタイルは絶対に上書きすることができなくなります。

.box .inner .inner2 {
  color: red !important;
}

あるいはこんな方法もあります。変更があるたびにスタイルを追加して、上書きを繰り返します。一応、誰がいつやったのかわかる程度のコメントを残しますが、無駄な上書きが繰り返されていることに変わりはありません。

/* 高津戸追加 2011.3.11 */
.box{
  color: red;
}
/* 田中追加 2013.1.15*/
.box{
  color: blue;
}

もちろんおわかりのように、これらは好ましくない解決法です。

万全の解決方法はある？

では万全の解決方法はあるかというと、どうやら現在のところそれはないようです。YahooのエンジニアNicolle Sullivan*はCSS is too fragileと述べています。

意味するところは「CSSはとても壊れやすいものだ」ということです。一度、サイトをオープンすると、多かれ少なかれ前述したような「CSSごちゃごちゃ」問題が起き、崩れていきます。ですから、なんとかその崩れる度合いを低減しながら、保守する必要があります。

その保守がうまくいくかどうかの鍵となるのが、初期段階での「CSSの設計」です。

CSSの設計に必要なこと

CSSを崩れにくく設計するには、ただCSSを書くだけではうまくいきません。本シリーズでは、ピクセルグリッドで実践されているCSSの設計方法を解説しますが、それを実践するには、ページの設計、デザイン、マークアップ、CSMやシステムの工程が全部関係してきます。理想を言えば、設計の段階から関わることがベストです。

とはいえ、多くのワークフローでは、マークアップエンジニアにPhotoshopやFireworksファイルなどのページカンプが回ってきて、これをコーディングする役割になることがほとんどということもあると思います。

その場合は、これまでの設計工程を整理するつもりで臨むことです。

さて、それでは具体的にどのように設計を考えていったらいいかを紹介しましょう。

枠とモジュールで考える

デザインをコーディングする際は、デザインを「枠」と「モジュール」で考えると、CSSの設計がやりやすくなると思っています。

「枠」というのは、モジュールをはめ込んでいくための枠組みです。「モジュール」というのは、レゴや積み木などの1ピース（部品）と考えてください。

枠の中に部品を積んでいくイメージで、デザインを捉えるのです。例えば、次の3カラムのページを見てください。カラムを「枠」と捉え、その枠の中にメニューやコンテンツなどの部品（モジュール）を並べていくと考えるのです。

枠は.frame-side、.frame-main、.frame-side2という具合にコーディングします。

.frame-side {
  ...
}
.frame-main {
  ...
}
.frame-side2 {
  ...
}

さらにその枠とは別に、モジュールはモジュールとしてコーディングします。

モジュールのクラス名は特に決まりはないのですが、ピクセルグリッドでは.mod-moduleAなど、モジュールを表す.mod-に続けて、モジュール名を書いています。

モジュールAの内包されるさまざまなHTML要素はすべて、モジュールAのクラス名.mod-moduleAを起点とした子孫セレクタを使ってスタイルを付けていきます。

.mod-moduleA { ... }
/*モジュールAの中のさまざまな要素のスタイル*/
  .mod-moduleA img { ... }
  .mod-moduleA .head { ... }
  .mod-moduleA .body { ... }
    .mod-moduleA .body h1 { ... }
    .mod-moduleA .body p { ... }
  .mod-moduleA .foot { ... }

このようにモジュール名を起点にCSSを書くと次のようなメリットがあります。

モジュール名さえかぶらなければスタイルの競合が起きない

前述したCSSコードでわかるように、モジュール内には.headや.body、.footなど、よく使われるクラス名があります。しかし、これらはすべて.mode-moduleAの中で有効になるように書かれています。もし、別のモジュールの中で同じクラス名が使われていても、競合することはありません。モジュール名がかぶらないように注意さえすればいいので、設計が比較的楽になります。

逆にモジュール名を付けずに、いきなり次のようなクラス名を好き勝手に使ってしまうと、自分が意図しないところで、そのスタイルが付いてしまうことがあります。

.inner { ... }
.top { ... }
.head { ... }
.body { ... }
.foot { ... }

モジュール名を起点にすると、このようなことが防げます。

スタイルの追加も安全

モジュール名がかぶっていなければ、モジュールに新たなスタイルを追加する際も、クラス名の競合が起こることはありません。安心してスタイルを追加できます。

モジュールのスタイルがまとまっている

モジュールのスタイルは1箇所にまとまっているので、モジュールのスタイルがどこに書いてあるのかわからなくなってしまうことはありません。

モジュールの一覧を作る

さて、モジュールやモジュール名の設計が終わると、いきなりページのコーディングを始めたいと思いがちですが、その前にまず設計したモジュールの一覧を作ることが重要です。

モジュールの一覧とは、具体的にはこんなものです*。1ページ内に設計したモジュールをすべて集約しています。

また枠に関しても、次のように一覧を作っておきます。

このような一覧なしにいきなり実際のページの制作を始めてしまうと、モジュールを作ったかどうか忘れてしまい、新たなモジュールを作るのか、それとも既存のモジュールが使えるのか、すぐには判断がつかなかったりします。

また目の前のHTMLに引きずられてしまい、同じモジュールを別名で何度も作ってしまったりします。これでは、量産の効率が落ちてしまいます。

一覧があれば、そこからスタイルやクラス名をコピー＆ペーストして作業を進めることができるので、間違いが発生しにくく、また設計者以外の他人に作業を振り分けることも簡単にできます。

つまりページの作成とは、枠を作り、モジュールを作り、それを一覧化してから、コピー＆ペーストして作っていくものであると考えるのです。このようにすることで、作業効率を大きく上げることができます。

まとめ

今回はCSS設計の考え方のひとつ「枠とモジュール」を解説しました。次回は、さらにモジュール名の名前をどのように決めたらいいか、また、モジュールをどのように切り分けたらいいかを考えてみます。