やはりSassは必要だと考えている。あるいはLESSでもStylusでも良い。それはCSS Variablesの実装が落ち着き、行き渡っても、だ。もちろんその時にはCSSプリプロセッサーの変数を使わずに、CSS Variablesを使って書いた方が良いけれども。
CSSプリプロセッサーの変数やネスト、そしてミックスインはショートカット記法に過ぎない。DRYを加速させるだけで、それ以上特に付け加えられる何かはあまりない。変数への命名規則の採用による意味付けやネストでの構造化は有用・有益であることには気づくが、本質的な意味付けや構造化をもたらすものではない。これらの機能はCSSの貧弱さと比較すると輝かしく見えるものの、プリプロセッサーを使ってまで利用する価値があるかというと疑問が残る。
ならばなぜ必要だと考えるのか。
それはウェブページの要素間でのルールセットの共有ではなく、セレクター同士での意味合いの共有を行える機能、Sassであるなら@extendがあることだ。これによりルールセットを意味のある固まりとして定義でき、複数のセレクターでその意味を共有できるようになる。これによりようやくOOCSSの真なる実現がなされたと言って良い。
つまりここに魅力を感じない、またはそれによるCSSとの乖離を問題視するのならCSSプリプロセッサーは不必要ということだ。@extendを根幹に据えたSassのコードは、CSSだけでCSSらしく書かれたCSSのコードとは大きく違ってくる。それは@extendを使ったSassの生成するCSSコードが複雑なことからも垣間見えるだろう。リニアに上書きされていくCSSとは違い、@extendを使ったSassのコードでは拡張され、継承されていく。
Sass 3.3では多くの機能が追加された。マップであったり@at-rootであったりだ。これらの機能はちょっと大仰で、CSSからかけ離れたものと感じ、もっとコンパクトな……いっそのことCSSに回帰しようと考えた、考えている人も多いだろう。
僕も少なからずそのような感じを持ったし、実際に新機能の多くは直接的な形では使うべきではないと感じている。これらはプレースホルダー・セレクターでカプセル化した中、またはプレースホルダー・セレクターから参照されるミックスイン等の中で使われるべきものだと思う。そう使うことにより、プレースホルダー・セレクターやその先ではSassを駆使してオブジェクトらしきものを作成し、それを多少ネストしたくらいのCSSらしく書かれたコードから参照していくように記述できる、というわけだ。
大きな変更に抵抗を感じる人も多いだろうが、これらの変更はCSSらしく書いた上でSassを使ってOOCSSを具現化できるといったような概念的な変化をもたらすものだ。こんな風に、複雑な機能が大量に追加されただけではないと捉えてみると、少し感じ方が変わるのではないだろうか。