Sassの問題点ははっきりしていました。同時に、CSSの新しい仕様たちは非常に明快で注目に値するものでした。この辺りを踏まえて純CSSへ戻ろうとしましたが、結果的に踏みとどまったので、その辺りの経緯をまとめます。
🙋♀️ そもそも我々はSassをなぜ使っているのか？
個人的に、チーム的にこんな感じでした。この辺りは人それぞれあると思います。
- クラス名を付けずにタグに対してスタイルを指定したいときにスタイル規則をネストしたい
- ソースコードの視認性を高めるためにコンテンツのセクションごとにスタイル規則をネストしたい
- 検索性を高めるために目的別・コンテンツ別にファイルを別けたい
- 大規模なプロジェクトでは色のパターンを定義して再利用したい
- メディアクエリの画面幅の数値を定義して再利用したい
- 大型のプロジェクトでは
@extendを利用してスタイルを共通化している - 一部のプロジェクトでは
@mixinを利用してベンダープレフィクスを共通化（最近はautoprefixerを使っているが）したり、スタイル規則を定義したり、ブレイクポイントを共通化したりしている
🤷♀️ Sassの何が困っているか？
1. 全ての機能がプリセットされている
利用していない機能もプリセットされている。チームとして、どの機能を使っていきたいか、の基準を明確化しなければ、新規参画したメンバーは片っ端から機能を使い倒し、レビューが辛くなる可能性が高い。
2. 言語の実装が複数あったが廃止されているので移行対応が必要
Dart Sassに加えて、Sass: Embedded Sass is Liveも出てきました。
3. 本質的に使用の方針が不安定になる傾向がある
Sassはリアルワールドで便利とされているCSS設計理論に合わせて、仕様を変化させるような、現実的な方針をとっています。以下の機能は現在進行形で廃止に向かっているので、過去のコードを変更する必要があります。
@import
@importだと階層的に@importを利用している場合でもスタイル規約にアクセスできるますが、この仕様が問題視されはじめ、代替案として@useが採用されました。これは呼び出したファイルでしかスタイル規約にアクセスできないようになります。
4. CSS本体の仕様とコンフリクトする可能性がある
/を利用した除算
CSSでは/を区切り文字とするプロパティがあります。
この時にSassからしてみれば、その/が区切り文字なのか、除算なのか区別がつかなくなってしまいます。これの代替案としてMath.divを推奨しています。
Sass: Breaking Change: Slash as Division
🤔 ところでCSSの動向は？
cssdb - CSS Database ではstageと呼ばれる、新しい機能の標準化への段階を定義しています。
| Stage | Level | 成熟レベル |
|---|---|---|
| Stage4 | Standardized（標準化） | 高 |
| Stage3 | Embraced（包容） | : |
| Stage2 | Allowable（許容） | : |
| Stage1 | Experimental（実験的） | : |
| Stage0 | Aspirational（野心的） | 低 |
Stageが上がるにつれて、実際にブラウザの対応状況も良くなっていっているようですね。
また、postcss-plugins/plugin-packs/postcss-preset-envではこのstageに準拠して、将来的に標準化されるであろう機能を利用することができます。
Sassでよく使っていたような機能も結構出てきているみたいですね。
| 実現したいこと | CSS | PostCSSプラグイン |
|---|---|---|
| ネスト | nesting rule (stage 1) | postcss-nesting |
| ファイル分割 | - | postcss-import |
| 色の再利用 | custom property (stage 3) | postcss-custom-property |
| メディアクエリの再利用 | custom media query (stage 2) | postcss-custom-media |
| クラス継承 | 議論中 | postcss-extend |
| Mixin | 議論中 1 | postcss-mixins, postcss-apply |
それぞれのルールの記法については、色々調べてみてください。
Mixinの用途別の再現方法
- 共通のスタイル規則を定義 => シングルクラスを採用しない
- ベンダープレフィクスの共通化 => Autoprefixer
- ブレイクポイントの共通化 => CSSのcustom media query
🫣 stageが低いルールの仕様はとても不安定
W3Cで定義されているstageは、正式なリリースバージョンではなく、その使用の安定性は低いです。
stageが低いものは、仕様が変更されたり、rejectされる可能性が高いことも考慮しなければならない。
CSSの草案に対しての知識や経験がほとんどないうちには、postcss-preset-envのデフォルト（stage 2）に従った方がいいと思われます。
例えば、nesting ruleはまだstage 1なので、仕様が変更される可能性が高いです。もしpostcss-preset-envで実装しても、もしかするとnestingの部分だけあとで実装し直す必要があるかもしれませんね。
😌 postcss-preset-envの採用はまだ早いかも
上の話でやっぱりpostcss-preset-envの採用はまだ早いかもしれません。
今後は、
- CanIUseなどを使ってブラウザの対応状況を見ていく
- もし使いたい機能のstageが4になり、ブラウザ対応が十分になれば採用する
- autprexierのように、CSS本体とは別なアプローチのためにPostCSSは採用を進めていく
かなと思いました。ありがとうございました。
-
@applyが議論されているが、技術的な課題があって難航しているらしい ↩