PostcssとCSS Level 4の現状と今後のCSSプリプロセッサとの付き合い方を考える

今もだが、当時はpostcss-preset-envを使った日本語情報はものすごく少ない印象だった。というか、vue-cliやらNuxt.jsとセットな情報とかしかない印象あったので、もっと上に包括した環境を用意していることが多いんだと思った。
フレームワークなどにセットで入っているCSSプリプロセッサを利用したりしているんだろう。

便利そうなPostCSSプラグインたちとそのリスク

さて、お察しの通り、PostCSSにはたくさんのプラグインがあり、どの機能を使うかに合わせてスキに入れていくことができます。

PostCSS.parts といったサイトもあり、どんなモジュールがあるか見てみるのがよいでしょう。

しかし、これらがすべてCSSの次期仕様でブラウザ上でネイティブに動くようになるわけではありません。
最たる例としては、postcss-simple-varsです。このプラグインは、Sassライクな記法の変数機能を提供しています。

また、別の例を挙げると、ネストを利用する機能を提供するプラグインは似たようなものが2つあります。

• postcss-nested
• postcss-nesting

このネストのプラグイン、どちらが仕様に近いかというと後者のpostcss-nestingです。
仕様を追って何を使うか判断……とてもめんどくさそうですよね。
そんなときに戻ってくるのがやっぱりpostcss-preset-envなのです。

postcss-preset-envが利用しているプラグインこそがpostcss-nestingなのです。

CSS仕様のステージに合わせて使えるのがpostcss-preset-envの強み

postcss-preset-envはオプションがあります。

• Stage 3 +
• Stage 2 +
• Stage 1 +
• Stage 0 +

3ほど実装される可能性が高いものです。（悲しいことに真逆の内容を書いている記事も見受けられます。）

もっとちゃんと言うと、CSSDBというところから情報を取って来ています。
W3C基準で表にしてみました。

とはいえ、これでわからない人も多いと思うのでめちゃくちゃ雑に言ってはいけないことを言います。
stage 3+の設定であれば、別にコンパイルとかする必要もなく各ブラウザのlatest2版くらいは通ります。

postcss-preset-envでは次のようなものがあります。

• all property
• break porperties
• custom properties
• font-variant property
• gap properties
• media query ranges

さて、注目すべきはやはりcustom propertiesです。
いわゆる変数です。

Can I Useで対応状況を見ると以下のとおりです。

CSSにおける変数は、IEを除いてブラウザネイティブに通ります。

ところで、カスタムプロパティを実現してきた、postcss-custom-propertiesには、preserveというオプションがあります。

postcssCustomProperties({
  preserve: false
});

このオプションでは次のように :root: 要素に定義されたカスタムプロパティをコンパイル後に残すか残さないかの選択ができます。

:root {
  --color: red;
}

デフォルトでは残ります。
これは変数はあくまでもコンパイル前の概念という人にはとても不思議に思えると思います。

ですが、ネイティブにブラウザが理解できるようになっているものなので、あくまでコンパイル後のものはすでに古いブラウザ対策でしかないです。

そういえば言い忘れていましたが、変数をJavaScriptで操作するなんてことも当然できます。

Sassがもう必要ないかもと考えることもできる。

Lessが私にとっての初のCSSプリプロセッサだったのですが、その一番の利用したい欲求は変数でした。その変数は、custom propertiesという形となり、ブラウザで利用できます。

ネストと言っている人も周囲にいた記憶があるので書いておくと、コンパイル後のCSSの管理がアンコントローラブルになりそうだなと、ふわふわした抵抗感を抱いていたのであまり使っていませんでした。

その後、Trello CSS Guidelineを翻訳しました。（Less前提ですが、基本的にSassに置き換えても問題ないので、話をわかりやすくそうします。）

この記事ではセレクタがコンパイル後にネストされていない範囲でしかネストを使うべきでない。といった旨が繰り返し説かれています。 （この説明をかつてできなかったのだけども、なんて言ったらよいのかで言語化できたことが誇らしいです。）

上記も含めて、Sassの機能をフルに使うことなく、運用体制に合わせて使用される機能を選択するべきだという考え方があります。（もちろん、一方で機能として提供されているんだから使えばよいって考え方もありますが。）

今後のCSSプリプロセッサとの付き合い方

さて、ここまでつらつらと書いてきたことを踏まえて、今後CSSプリプロセッサをどう扱うかを考えます。

Sassを部分的に利用する

変数はcustum-propertiesの形式に乗っ取り、他の利用したい機能を利用するという方法です。
既存のプロジェクトをモダンな形に近付けるための一歩としてやるのは意味があります。

PostCSS + postcss-preset-envを利用する

PostCSSを利用する明確な基準としてpostcss-preset-envを利用します。
Level0になると、実装されるか怪しいものもあるが、applyルール（いわゆるmixin）はこのレベルでないと使えなかったりします。
他のプラグイン何でも使えばよい方式は、個人的にはそれはもうSassの方が優位性高いのではとなるので書きません。

生のCSSを使う

最近はスコープを持たせたCSS構造のプロジェクトに関わることもあって、そのプロジェクトではSassが使われていたのだが必要ないなという印象がとても強かったです。
思うに、スコープ切られていると細分化された中で最適化していけばよいという思考が働いたのだと思います。
変数を使いたい欲求は一方であったので、グローバルな扱いのところでカスタムプロパティ定義しておけば十分やっていけるなと思いました。

Sassがデファクトスタンダードでありつづけることを支える基盤

置き場所悪かったかも。 #FROKAN pic.twitter.com/X352PxV6L6

— LINLY (@linlymatsumura) March 14, 2018