CSSの記述法として、ブラウザごとの違いを「Reset」して一から指定するという方法が長らくマジョリティを占めていました。まだまだその方向で書いている人が大半ですが、「Normalize」するという方法を採る人達も増えています。なぜリセットではなくノーマライズなのかというような話をなんとなくダラダラ書いてみたい感じです。

以下、リセットはYUI 2CSS Resetを、ノーマライズはNormalize.cssをイメージして読んでみてください。

リセットとノーマライズ

まずは両者の違いから。リセットはなかったことにするというもので、ほぼ全ての要素に対するスタイル指定を排除しブラウザごとの違いを吸収するものです。対してノーマライズはブラウザのデフォルト・スタイルシートを生かしつつ、各ブラウザ間の挙動を擦り合わせるものです。リセットが負の方向で統一しているとすれば、ノーマライズは正の方向で統一していると言えるでしょうか。

例えばリセットではulli要素に対して以下のような指定がなされています。

ul {
  margin: 0;
  padding: 0;
  list-style-type: none;
}

li {
  margin: 0;
  padding: 0;
}

対してノーマライズでは以下のように指定されています。

ul {
  margin: 1em 0;
  padding: 0 0 0 40px;
}

両者の思想の違いがはっきりとわかるのではないでしょうか? リセットではリスト項目のインデントはおろかリストのブレットも消し、単なるコンテナに変貌させているのに対して、ノーマライズではインデントのアプローチを揃えるだけにとどまっています。この違いは後のスタイル指定に大きな影響を与えることになります。

なぜノーマライズなのか

ブラウザの違いを吸収するという点では両者ともに一定以上の効果があり、実はそれほど差がありません。リセットの方が自由度が高く楽だとも言えるでしょう。スタイルの継承などを意識することなく、自分のデザイン・アイディアをそのままCSSコードに一対一で変換するだけなので、CSSの習熟度があまり問題にならないという点でもリセットは取っ付きやすく優秀です。

そんな便利なリセットではなくなぜノーマライズなのかと言えば、「必要な分だけCSSを書けば良い」ということがまず挙げられるでしょう。

例えばこのサイトのようなあまりごちゃごちゃしていないようなデザインの場合、ノーマライズを利用すれば背景画像とヘッダとフッタのレイアウトだけでほぼ完成になります。リセットを使う場合は段落のマージンを始めとした様々な要素のスタイルも改めて指定し直す必要があるので、結構な作業量になります。必要な分だけ書けば良いというのはCSSコードの見通しの良さに直結するので、バグやちょっとした不整合にも対処しやすくなるでしょう。

「必要な分だけ」は最終的なCSSファイルのサイズが減るというような即物的な利点にもつながります。

仕様の変化とそれへの対応

リセットでは新たな仕様がどうブラウザに実装されているかを考慮して必要ならば対応しなければなりません。そうしないと他の要素やプロパティとの整合性がとれなくなります。ユニバーサル・セレクタを使って強引にリセットしてしまうという方法もあるでしょうが、弊害が多く最近は誰も使いません。

ノーマライズにおいても最終的に対応する必要は勿論ありますが、リセットと違いブラウザのデフォルト・スタイルシートから大きくかけ離れるようなものではないので、とりあえずはブラウザの実装のまま表示されても大きな問題が起こることはないでしょう。そういう意味で柔軟性が高く将来に渡って安全な手法だと言えます。

リセットはもう不要なのか

向き不向きがあるということに過ぎません。例えばグリッドを重視して縦方向(行間)のリズムにまで気を配りたいというようなケースではリセットを使う方が向いているでしょう。つまり「CSSでどこまで細かく制御したいか」というのが指標になります。CSSフレームワークのような確実性を持たせる必要があるものでは、ノーマライズでは不測の自体が起こりやすく、その利用者に優しくないであろうため不向きになるでしょう。対して少人数でのラフなWebサイト構築にはノーマライズの生産性が遺憾なく発揮されます。逆に一人でなんでもできるような場合はリセットでコツコツ組み上げるというのも悪くない選択肢だと思います。


既存のサイトをリセットからノーマライズに移行させるメリットはまったく無いと思うので、まだまだリセットの時代が続くと思います。しかしながらリセットもその柔軟性の無さからUA検知のように緩やかに死ぬ運命にあるような気配はあります。それに備えてノーマライズのようなFeature Detectionと同じように将来における安全性を意識した手法について模索する必要があるのではないでしょうか。