Write with Sass, Compile to Standard CSS, Review, Optimize with Grunt, and Publish。

Frontrend Advent Calendar 2013の4日目の記事として、「CSSポストプロセッサー時代の到来」というタイトルで寄稿した。このウェブログで書こうかと思ったけど、意識はされていないもののそこそこ浸透している概念の話で、トレンドに関わりがあるもののそれに左右はされない話でもあるので、独立した文書にした。長いかと思ったけどそんなに長くもなかった。

CSSポストプロセッサー時代の到来ではさらっと流した、CSSプリプロセッサーのコードと標準的なCSSのコードとのギャップが大きくなりすぎてることについてちょっとだけ。

これは危険な徴候だなーと思ってる。例えばMedia Queriesを効率的に記述するためにミックスインにするみたいなのはよく見るけど、実装の仕方はSassのバージョンと人によりそれぞれで、意図とどういうコードが吐かれるかを把握するのはかなり大変。

.test {
  color: green;

  @include mq(480px) {
    color: red;
  }
}

3.2から使える@contentを使ったこういうミックスインはよく見るし、増えている気がするけど、もうCSSの感覚じゃない。もちろんmq()だったり、media()だったり、min-width()だったり、ipad()だったりもする。さっさと3.3に上げて普通に@mediaで変数を使った方が誰にでもすぐ読めて明らかに良い。このように簡略化を汎用化すればするほど書かれるコードの先が見えなくなっていき、よくわからないジャーゴンの習得を強要され、また強要する日々が待っていて、誰も幸せになれない。ドキュメントをちゃんと作っても、作った端から腐敗していくのは目に見えている。

グッド・ラッパーとなりうるのなら良いのかもしれないけど、Sassの機能は低く、グッド・ラッパーを書くのはRubyとの連携なしにはかなり難しい。やるとしたらCompassクラスの巨大なものを作らざるをえないと思う。

ウェブ標準でできることならなるべくそれで書いた方が望ましく、将来にわたって安定したコード・クオリティーを提供できるはず。というか泡沫のような技術で溢れるインターネットでは、ウェブ標準くらいしか信頼できる落とし所がない。DRYや楽をするという考え方は正しいけど、それだけじゃなくてウェブ標準に寄せる形で楽をするということも意識してミックスインやプレースホルダー・セレクター、そしてパーシャルを書くのが良いと思う。


その上で機械的に行える作業はCSSポストプロセッサーに任せると更にスッキリするよね! という話。

CSSポストプロセッサーという言葉は聞き慣れないと思うけど、やってることは機械的な最適化作業の分業化にすぎないので、似たようなことを既に実践している人も多いと思う。既にGruntを使っている人はほとんどそうなはず。こういうのをある程度共有できる概念としてはっきりさせると良いのかなと思って書いた。