cssnextを使うべきか

cssnextは、未来のCSS構文を今のブラウザでも解釈できるようにトランスパイルするPostCSSプラグインだ。そう聞くとさも、将来のCSSの書き方をそのまま先取りできる素晴らしいツールであるような印象を抱く。だが実際は、cssnextで表現できる形と標準の仕様は大きく異なっていることがある。cssnextを前提にして書いたコードは、未来のブラウザで違う挙動をする可能性があるということだ。

cssnextは、単一の機能を持ついくつかのPostCSSプラグインをまとめたプラグインセットだ。それぞれのプラグインは単に、ある構文を現在のブラウザでそれっぽく動くコードに変換することしかできない。対象とされている構文の多くは、現状の実装でフォールバックすることが不可能であるため、プラグイン作者の主観に基づいたなんちゃって実装に置き換えるしかないのだ。
そのため、cssnextを通して利用できる構文のいくつかは、実際の仕様と異なった形で利用する必要があり、仕様と異なった挙動をするコードを生成する。

標準の仕様と異なった利用方法をするプラグインとして、postcss-custom-propertiesは顕著な例である。カスタムプロパティは、動的でDOMスコープのプロパティであるという仕様だ。対してこのプラグインでは、プリプロセッサ上でのみ有効な変数として解釈されて、Sassのように静的な値に置き換えられる。これではカスタムプロパティを利用する意味が変わってしまうので、本来の仕様の意図から外れたコードを書かざるを得ない。

ほとんどのプラグインは、仕様通りの挙動を実現できないにも関わらず、無理やり標準の構文を利用することを目的にしてしまっている。それによってもたらされる弊害は、標準の構文を利用できるという利点よりも大きいだろう。
ユーザーが標準の仕様を誤解してしまうことも考えられるし、コードが仕様通りに動かないことを理解するためにプラグインの知識が必要になることもある。

また、標準と言えども破棄されてしまう仕様もある。仕様を追い続けた上で、利用していた構文が使えなくなったと決まれば、既存のコードを書き直す必要もあるだろう。

だったら無理に未来の構文に憧れを抱くのではなく、プリプロセッサの独自構文に身を委ねてしまったほうが安心できるはずだ。幸いSassは市民権を得た当たり前の言語になった。極端なコードを書かない限り、Sassに依存していることは大きな問題にならない。プリプロセッサ無しでみんなが書きたいCSSを書けるようになるのは、どうせかなり先の未来だろうし。


蛇足ながら、妥当に利用できそうなプラグインについても考えた。基準は次のふたつ。

  • 未来の仕様と全く同じ挙動を実現できる(単に糖衣構文である)
  • 仕様自体が破棄される可能性が高くない(Working Draft以降)

これに基づいて次のプラグインを選択できた。

列挙した全てのプラグインがベースにしている仕様は、現在Working Draftだ。慎重に考えるとどのプラグインも利用すべきではないのかもしれない。とは言え、僕にも未来の構文を使いたいという願望はある。ちょっとした個人プロジェクトでは利用してみたい。