3ステップでCSS設計のプロセスを振り返る
最近サイトのCSS設計の「手順」を人に教えるという機会があったのですが、普段は意識せず行えていることでも、いざ他人に教えるとなると、普段自分はどういう手順でCSS設計を行っているのか、思わず言葉に窮してしまいました。
そこで今回は、筆者が普段どういうプロセスでCSS設計を行っているのか、3ステップで振り返ってみたいと思います。
※ これから記載するものは、あくまでも筆者個人の手順となります。
ステップ1 デザインをモジュールに分類する
まとまりのある機能を持った部品のことをモジュールといい、Webサイトでいうと、見出し、ボタン、ヘッダー、フッター、などが該当します。まずはデザインカンプをじっくりと眺め、モジュール別に分類、また、同じモジュールの中でもさらにデザイン別にグループ分けを行います。
モジュール別に分類とは、見出し、ボタン、フォーム、レイアウトなどに分けることを指します。また、モジュールの中でのデザイン別の分類とは、例えば同じボックスモジュールの中でも、デザインが著しく異なり、CSSを少し変更するだけでは共通化することができないものに分けることです。
モジュールをどれくらいの単位で分類するかに関しては、はじめのうちはBootstrapやFoundationなどの有名なCSSフレームワークを参考にすると、よいヒントを得られるかもしれません。筆者はモジュールの分類に慣れるまではデザインカンプを印刷し、モジュールだと思われる場所をペンで囲い印づけをしてモジュールの分類を行っていました。
ここでのポイントは、細かくモジュールを分類し過ぎないことです。モジュールは汎用性が高い（どこでもそれ単体で用いることができる）のがよいとされていますが、逆に汎用性があり過ぎてもサイトデザインのトーン＆マナーを損ねてしまいます。
例えば下の画像のようなデザインのモジュールの見出し部分を考えるとします。
仮に、他に汎用見出し（サイトの中で主に使われる見出し）のデザインが既にあり、かつ、このボックス内の見出しが、ボックスの中にしか登場しない場合、この見出しは、それ単体でモジュールに分類するか、このボックスモジュールの一部として捉えるかであれば、筆者は後者を選択します。 理由は、このボックス内の見出しだけをモジュールとして切り出してしまうと、第三者によって、デザイナーや設計者が意図しない組み合わせで用いられてしまう可能性が出てきてしまうためです。
ステップ2 自分の中のコーディングルールを決める
デザインの分類を済ませたあとは、コーディングをはじめる前にHTML/CSSコーディング上のルールを策定します。自分で定めるルールとは、サイト全体の仕様策定とは別の、主にコーディング記述の品質を統一し担保するルールです。お客様より特に希望や指定がなく、既存ガイドラインが存在しない限りは、筆者は主に下記をあらかじめ定めています。
- HTML
- インデントの有無
- 改行・空行のルール
- モジュールとモジュールの間の改行ルール
- モジュールの中の改行ルール
divの要素やリスト要素、テーブル要素以外は基本的に不要な改行は用いない、など
- サイト内のリソースの命名規則
- 画像ファイルの命名規則
- 共通リソースの画像ファイルの命名規則
- ページ固有の画像ファイルの命名規則
- その他、PDFをはじめとするファイル名の規則を決める
- 画像ファイルの命名規則
- サイト内のリソースの格納フォルダのルール
- 共通リソースの格納先と、
- アンカーリンクの命名規則
- ダミーの記述ルール
- ダミーリンクの書き方
- ダミーテキストの書き方
- ダミー画像の書き方
- CSS（SCSS）
- id/class命名指針
- プロパティの記述順
- CSS（SCSS）整形に関する項目
- 小数点前の0は省略、プロパティ後ろに半角スペースを挿入する、など
- そのほか、CSS（SCSS）全体で統一したいの記述ルール
- フォントサイズの単位やマージンの方向
- コロンやセミコロンのスペースのルール、また小数点前の0の有無など
- SCSSであれば、ネストの回数やコンパイル形式の指定など
記述ルールに関して細かくルールを策定する理由は、自分以外の第三者の更新を常に念頭に置いているからです。ルールが決まっていないと、各更新作業者の日頃の癖がソースコードに表れてしまい、コードの可読性が損なわれてしまう遠因になったり、全てのページの品質を担保することが難しくなる可能性が出てきてしまいます。
ただし、CSSプロパティの記述順やコロンやセミコロンのスペースのルールなど、コード整形系のルールに関してはタスクランナーなどの力を借ります。こういった規則性のある仕事は人の手でやるよりも、機械の力に頼った方が効率的で確実です。
id/class命名指針
SMACSS、BEMなど、様々なCSS命名ルールが存在しますが、どの命名規則にも優劣はありません。キャメルケース、ハイフンつなぎをはじめ、どのようなパターンを用いるにせよ、ポイントは下記の2点だと筆者は考えます。
- サイト全体を通して命名ルールが一貫している
- キャメルケースやハイフンつなぎが規則性なく混在しない、など
- 他人がコーディングルールを把握せず、ソースコードだけ読んでもCSS命名規則が粗方把握できる
- 省略し過ぎない、特殊過ぎる接頭辞は極力利用を控える、など
どちらのポイントも結論としては、第三者が見てもわかりやすく把握しやすいCSS命名規則を心がける、ということに通ずるのだと思います。
ステップ3 コーディング
ルールを決めたら、それに則りコーディングをはじめます。コーディングをしている途中で、ステップ2で決めたルールに例外が出てきたり、うまく適用できないケースは多々出てきます。そういう場合は、全体が破綻しない程度にルールを追加したり修正します。
ここで注意したいのが、一部ルールを修正したことによって成果物全体のルールがぶれてしまわないことです。特に、CSS命名規則はコーディング中に迷いが生じやすく、途中何回かルールを修正したくなる箇所ですが、はじめのうちは「完璧な命名規則」を目指すのではなく、「自分なりに一貫している命名規則」を目標にしてみてください。
HTMLコーディングの順番について
筆者はまず「ガワ」とよばれる、ヘッダーやフッターなどサイトの大枠のレイアウトからHTMLコーディングを行っていきます。モジュールが入っている入れ物から作っていくイメージです。サイトのレイアウトについて何パターンかある場合は、下層ページで頻出するような基礎的なレイアウトをテンプレートとして作成し、次にモジュールを作成してしまいます。
モジュールも、基本的には汎用的なモジュールから作成していきます。汎用的なモジュールができていれば、設計作業が全て終わっていなくても実装フェーズが開始できることと、汎用的なモジュールはデザインが特殊なモジュールに比べて途中で修正されにくいためです。また、モジュールは「見本」となるHTMLであり、複製されサイト内に配置されるHTMLでもあるため、改行や閉じコメント位置にも留意します。
CSSコーディングについて
CSSコーディングに関しては、「サイト全体に関わるCSSプロパティ」からスタイルをあてていきます。セレクタには優先度が決まっており、優先度が高い記述をそれより優先度が低い記述で上書きすることはできません。そのため、自然とCSSは上から優先度が低いプロパティから記述していくことになります。まずは要素セレクタや全称セレクタ（あれば）に適応させるようなものから記述していき、汎用モジュールに関連するCSSから作成していきます。木彫りのように、まず大まかな形を作り、徐々に細部を作りこんでいくイメージでしょうか。
ここでのポイントは、「モジュールの疎結合」です。
壊れやすいCSSの傾向のひとつとして、モジュールのCSS同士が依存関係にあり、1箇所を修正すると他の箇所にも意図せず影響してしまう、といったパターンが存在すると思います。
モジュールに分類したら、モジュールを親セレクタとし、特別な理由がない限りそれ単体で完結するようにCSSを記述していきます。例えば、他のモジュールの隣にないとスタイルが適用されない、また、特定のIDが振られたページの中でないと色が変わらない、といったような書き方はしないようにしましょう。
CSS設計のベストプラクティスはたくさんありますが、まずははじめの一歩として、「他のモジュールに影響しないCSSを書く」というところをゴールとしてみるとよいかもしれません。
まとめ
やはりCSS設計は整理や分類が肝となるのだな、とプロセスを棚卸しながら改めて実感しました。
CSS設計は経験を積むことで、モジュールを見分けられたり、コーディング前に策定した方がいいルールというものが感覚的にわかってくると思います。そのため、最初は細かくルールを作ろうとせず、最低限「サイトの中で統一されている」ルール作りを目指してみてはいかがでしょうか。