およそコーディングにおいては書きやすさが重視される傾向が強い。例を挙げるまでもないだろう。しかし、その書きやすさは主観的なものであることが多く、他人の読みやすさへは寄与しない。読みやすさにも主観的な面はあるが、それでも落とし所というものはある。ただ、そういった読みやすさは人間へのもので、機械とそれを通して利用することになるユーザーに優しいとは言えないことが多い。これらすべてを満たす夢の書き方みたいなものは、特にフロントエンド開発においては、なかなか存在しない。
開発においては以下の様な形でワークフローを構築したい。それぞれの段階で対象になる人が違うことが重要だ。
CSSの開発においてこれらに対応するものを具体的に挙げると以下の様になるだろう。
もちろんSassだけではなくてLESSでもStylusでも良いだろうし、Clean CSSの代わりにYUI Compressorでも良い。もっと抽象的な形で書くと以下の様になる。
Sassで自由に書くが、一旦ウェブ標準仕様に落とし込み、如何ともしがたい現実への対応は機械的に行うという形だ。このような形でのCSSの開発では、ざっと以下の様な利点があるんじゃないかと考えている。
欠点ももちろんある。一番大きいのは段階が増えることによるコストと作業量の増加だ。機械的な作業を行う頻度を下げるようなワークフローにすることによってある程度までは解決できるが、大きな単位での作業では辛くなるだろう。単純にツールの利用が増えることから、それらの知識も必要になるというような学習コストも見逃せない。
できることならウェブ標準仕様に基いて書き、それで終わりが良いのだけど、現状では文法における理想と実装における現実のどちらからもかなり遠いので、1と3では必ず何らかのツールによるサポートが必要になる。まずはこのような形に移行して、CSSの文法強化を受けて1を捨て、ブラウザーの内部的な進化を待って3を捨てる、というような段階を踏んでウェブ標準の未来に飛び込みたい。一足飛びにウェブ標準仕様に寄せるというのも悪くはないだろうし、できればそうしたい気持ちはあるが、まだストレスが多すぎるので僕はやりたくない。
僕の中ではCSSプリプロセッサー及びCSSポストプロセッサー(と呼んでいる機械的な変形を行うツール群)はこういった開発の変化の段階を踏むための手段に過ぎない。特にCSSポストプロセッサーは無くても良いものである必要がある。だから統合的なツールではなく、単機能でいつでもリスクなしで削除できるような形で提供されていると良いかなと思ってもいる。
同時に、CSSプリプロセッサーではウェブ標準から離れすぎないように書く方が良い(「べき」に近い)とも思う。Sassでセレクターのインターポレーションはしないとか、複雑な分岐を含んだメディアクエリのミックスインは書かないとか、だ。しかし@extendのようなOOCSSのあり方の理想に近い機能を中心に据えて使うとか、同じメディアクエリでもネストを使って関連するルールセットがまとまるようにするとか、単なるシンタックス・シュガーに留まらないものは使う方が良いはずだ。そういったものは書きやすいだけでなく、メンテナンス性の向上にもつながるからだ。
こういった両ツールの支えによって、ウェブ標準仕様へ準拠したCSSで完結する世界への穏やかな移行が成せるのではないか。そう考えている。