Normalize.cssを始めとして、Twitter BootstrapやPureに至るまでCSSのライブラリーは数多くある。それらはそれなりに気をつけて作られているが、他のライブラリーと混ぜることはもとより、ページ制作者のCSSと混ぜることは想定されていない。単純にlink要素を使って先に読ませるか連結するだけで使わないと、開発者はもちろんそれらが使われているページのユーザーにも意図しない不具合が起きる可能性がある。
そのためNomralize.cssなどではわざわざ以下のように推奨されている。
It is recommended that you include the normalize.css file as untouched library code.
概ねライブラリーと呼ばれるものには手を付けるべきではないが、フロントエンド界隈では軽視されている傾向があるように思う。特にCSSにおいては何よりもまずルールセットの記述順が重要になるため、不可逆な変更を行う最適化ツールはCSSライブラリーと相性は良くない。公式に配布されている最小化済みのものそのまま何もせず使うのが確実だ。
ただ最近は様々な最適化・最小化ツールやそれらを効率的に扱えるビルド・ツールがあるため、公式には最小化済みのものが配布されていないこともある。その場合の判断は難しいが、安全第一なら最小化されてないものをそのまま、バランスをとるなら別個に最小化のみ行いそれを使うのが良いだろう。
Gruntやgulpのようなビルド・ツールを使う場合は以下のような順序で処理するようにするべきだろう。
手順1はSassなどで行っても構わないだろう。手順2の最適化にはCSSスプライトの生成ツールやUnCSSのような非可逆なツールでの作業が含まれ、手順3では可逆に近い安全な変換作業を行う。ここで自身で書いたCSSを一旦完成させ、最後にCSSライブラリー群と連結させるという形だ。
このようなやり方だと開発中(手順1の辺り)ではCSSライブラリーが含まれない状態になるが、開発中にはパフォーマンスに目をつぶってlink要素などでCSSライブラリーを読みこめば良い。パフォーマンスに類する問題は別に計測と解決を行うべきと考えられるので、大きな問題は起こらないはずだ。
このような形でビルドすることのメリットはCSSライブラリーが配布された状態そのままであることが保証されることが挙げられ、それが全てと言って良い。他にライセンスが書かれたコメントを確実に残すことができるというような副次的なメリットもある。ビルド時間も少し速くなるが、それはプロダクションのファイルが少し大きめになりやすいことと相殺される程度のメリットで、特筆するべきようなことではないだろう。
僕の作っているModularized Normalize.cssはページ制作者のCSSに混ぜ込むことを目的としたものなので、このあたりの主張と対立するものだ。が、これについては少し目的が違う。そのうち書くような気がするかもしれないこともない。