CSS設計 第一回 CSSが抱える課題

はじめに

社内でおすすめのCSSフレームワーク選定について質問されましたが、
明確な答えを持たなかったので本記事を通して自分なりの意見をアウトプットしたいと思います。
今回は第一回として、CSSが抱える課題について触れていきます。
CSSフレームワークについて話をする前に、このあたりの話を整理しておいた方が建設的な意見になると考えています。

• 第一回 CSSが抱える課題
• 第二回 CSSの設計手法
• 第三回 CSSフレームワーク

CSSが抱える問題

プレーンなHTMLとCSSを使ったページをユースケースとして考えます。
設計手法やフレームワークは、これから書いていく課題のとの解決策として上がってくると思いますが、第二回でそれらには触れていきます。

グローバルなスコープ

CSSのスコープはグローバルです。
グローバルということは、以下のような問題を発生させます。

• どこからでも参照ができてしまう
• 上書きができてしまう

上記の問題によって生じる不都合は何でしょうか。
開発者に必要のないクラスやプロパティの追加を許容することだと考えます。
複数のページを跨いで共通で読み込まれるCSSファイルを例に考えてみます。

例. ページAとページBで読み込まれるbasic.css
bacis.cssは汎用的なボタンのCSSを定義した共通ファイルと仮定します。

basic.css

.button {
  background-color: blue;
  width: 150px;
  height: 50px;
  font-weight: bold;
  color: white;
}

Q. ボタン赤くしたいんだけど

ある日、ページBで表示するボタンの色を赤く変更したくなりました。
ただしページAのボタンの色を変更したくありません。
この場合、開発者がとる選択肢は、大抵以下のいずれかになると思います

1. ページB用の新しいCSSファイルを作成して、背景色を赤にするCSS定義を追加する
2. 共通CSSに背景色が赤のボタンを表示できるCSS定義をする

赤いボタンはページBでのみ使われるため新しいCSSファイルを作成する方が自然だと考えます。

pageB.css

.bg-red {
  background-color: red;
}

ページBで表示するボタンは.buttonと.bg-redのクラスが併用されるようになりました。
この時点では問題は発生していないように見えます。

Q. ボタン大きくしたいんだけど

別のある日、ページAのボタンを大きくしたいという要望が出てきました。
.buttonクラスはページBで使われているクラスでした。
basic.cssを変更するとページBのボタンまで大きくなってしまいます。開発者はどうするでしょうか。

1. ページA用のCSSファイルを作成して、ボタンを大きくできるCSS定義をする
2. 共通CSSにボタンを大きくできるCSS定義を追加する

ボタンを大きくするという要件は、ページAの話ですから新しいCSSファイルを作成するのが自然なような気がします。

pageA.css

.btn-large {
  width: 300px;
}

ページAで表示するボタンは.buttonと.btn-largeのクラスが併用されるようになりました。

ここで改めてbasic.cssを見てみたいと思います。
共通定義のはずが、background-colorとwidthは単一のページでしか適用されない値になってしまいました。
それぞれのページの都合にそぐわない状態となっていて、すでに.buttonは汎用的なボタンのCSS定義の役割を失ってしまっています。

basic.css

.button {
  background-color: blue; /* ページBでは 'red' */
  width: 150px; /* ページAでは300px */
  height: 50px;
  font-weight: bold;
  color: white;
}

見た目が表現できていれば良い？

このくらいの規模であれば、basic.cssの.buttonの定義は消去して、pageAとpageBそれぞれで使用するCSS定義をすることができると思います。
ただし現実のプロジェクトでは、basic.cssは100行、200行あるかもしれないし、pageA.cssについても同様です。
またbasic.cssはページCやページDでも読み込まれているかもしれません。

ボタンの大きさを変えるだけなのに、他のページに影響が出るかもしれない共通CSSの掃除をするコストを払うでしょうか。
上書きを上書きするような新規のクラスを定義してしまうかもしれません。
加えて、pageA.cssはpageAのレイアウトを拡張したページでも使われてしまうかもしれません。その場合pageA.cssはbasic.cssと同じ道を辿る可能性があります。

そうして本来必要のないCSSが大量に発生して、開発者はどのくらいの無駄があるかを把握する手段も無くなってしまいます。
(grepして地道に必要なCSSなのかみていくことはできるかもしれませんが、やりたくない)
こうしてカオスなCSSはできていきます。
カオスなCSSは変更の影響範囲を難しくします。意図したスタイルの変更が適用されなかったり、セマンティックなHTMLを維持できなくなります。

また、ユーザーのいるWebサイトで読み込まれるリソースは軽い方が良いことは明らかです。
しかし、CSSの変更は往々にして、見た目が表現できていれば良いだろうという考えに陥りがちです。
保守性の観点でもサーバーサイドやインフラに比べて軽視されてしまうのはある程度仕方ないかと思います。

良いCSS

では良いCSSの定義は何でしょうか？
Googleのエンジニアが4つのポイントが紹介しています。

• 予測できる
• 再利用できる
• 保守できる
• 拡張できる

・予測できる
「スタイリングが期待通りに動くかどうか」。意図した部分に変更が行われるか。
大きなサイトでは必須になる考え方。

・再利用できる
既存パーツの再利用をすることができる。UIコンポーネントの抽象化が適切にされている

・保守できる
新しいモジュールや機能の追加をした時に既存のCSSをリファクタリングする必要なない状態

・拡張できる
複数のエンジニアで保守が容易であること。保守をするために必要な学習コストが高すぎない状態

詳細は引用元を参照してください
引用: https://philipwalton.com/articles/css-architecture/ (CSS設計完全ガイド
～詳細解説＋実践的モジュール集)

まとめ

CSS自体は簡単です。書いたプロパティの足し算です。
CSSの難しさは、設計部分にあって、グローバルスコープにどう対処するのかということと、CSS自体が開発・保守の範囲で軽視されがちであることだと考えます。
つまり無秩序な状態をいかに仕組みとして回避するかです。
次回は、具体的なCSSの設計手法について紹介をしたいと思います。

参考図書

CSS設計完全ガイド 詳細解説＋実践的モジュール集