設計
CSSの設計
第1回 枠とモジュールで考える

このシリーズでは、なるべくメンテナンスしやすい、可読性の高いCSSを設計する考え方を解説します。第1回目は、現状のCSSの問題点と、枠とモジュールで設計する考え方を紹介します。(監修:フロントエンド・エンジニア高津戸 壮)

2013年 02月21日発行

目次

初出

この文章は『CSS Nite LP, Disk 26「CSS Preprocessor Shootout」』で高津戸が行った講演「CSSの設計」を元に、テキストとして再構成しています。

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」問題

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

重複するクラス名

先ほどの例では、boxinnerというクラス名を付けていますが、このクラス名が、サイトの別の場所で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と述べています。

*注:Nicolle Sullivan

本シリーズの後半で詳しく説明しますが、OOCSS(オブジェクト指向CSS)という考え方を提唱した人です。

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

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

CSSの設計に必要なこと

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

コードを書くだけでは設計はできない
崩れにくいCSSの設計をするには、ページの設計から関われることがベスト。それができなければ、ページの設計を整理する心構えが必要。

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

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

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

枠とモジュールで考える

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

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

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

「枠」と「モジュール」

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

枠のコーディング
例示したページの場合、3つの枠があると捉え、それぞれを適当なクラス名を付けてコーディングする。
.frame-side {
  ...
}
.frame-main {
  ...
}
.frame-side2 {
  ...
}

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

モジュールのコーディング

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

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

1モジュールのコーディング例
.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ページ内に設計したモジュールをすべて集約しています。

*注:サンプルにしたサイト

このシリーズでサンプルとして挙げているのは、弊社と株式会社SINAPで制作した星海社が運営する「ジセダイ」というサイトです。

モジュールの一覧(部分)
作成したモジュール名とそのスタイルが確認できるモジュール一覧。本来はすべてのモジュールがリストされているため、もっと長いページになっている。【全体画像はこちら

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

枠の一覧:全幅
枠が1つの場合の一覧
枠の一覧:2カラム
枠が2つの場合の一覧
枠の一覧:3カラム
枠が3つの場合の一覧

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

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

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

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

まとめ

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

高津戸 壮
高津戸 壮
フロントエンド・エンジニア

Web制作会社、フリーランスを経て、株式会社ピクセルグリッドに入社。数多くのWebサイト、WebアプリケーションのHTML、CSS、JavaScript実装に携わってきた。受託案件を中心にフロント周りの実装、設計、テクニカルディレクションを行う。スケーラビリティを考慮したHTMLテンプレート設計・実装、JavaScriptを使った込み入ったUIの設計・実装を得意分野とする。 著書に『改訂版 Webデザイナーのための jQuery入門』(技術評論社、2014年11月14日)がある。 CSS Nite 2011ベストセッションにおいて、全170セッションの中から、ベスト10セッションに、CSS Nite 2013ベストセッションでは、全278セッション中、ベスト20セッションに選出。

外村 奈津子
外村 奈津子
エディター

情報出版社に在籍中、Mac雑誌、中高年向けフリーペーパー、コラムサイト運営、健康食雑誌、グラフィック・Web技術書籍編集、IT系ニュースサイトの編集記者を経験。その後フリーランスのエディター/ライターとして独立。2011年4月より株式会社ピクセルグリッドへ入社。ピクセルグリッドが提供するフロントエンド技術情報を提供するサービス「CodeGrid」の編集を担当している。