このウェブサイトのCSSから@mediaルールを極力なくした。今は亡き(殺した)CSS MQPackerへのモチベーションがゼロになったことをきっかけに、段階的に進めている。全廃はまだ難しいので、カスタム・プロパティーに代入していく@mediaルールだけに絞り、それ以外でもなるべく使わない、という方針にした。
普通のCSSであるルールセット側はごくシンプルなコードになる。var()が多いけれども。よくあるプロパティーの上書きが起こらないので、メディア・クエリーがなかった時代のCSSっぽくなる。メディア・クエリーによるプロパティーの上書きを、カスタム・プロパティーによる値の動的変化に置き換えている、と説明できる。
あらかじめ設定したカスタム・プロパティー群をデータと捉え、そのデータを参照する側に@mediaルールのようなロジックに相当するもの書かない、という見方もできる。これを踏まえてロジックレスCSSなどという説明をしている。
@mediaルールの問題点は、書き方が難しいところだ。まとめて書いても、個々に書いても、問題が起こる。
モバイル・ファーストで、@mediaルールをCSSの最後の方にまとめていくと、関連するスタイルが離れたところに書かれてしまう。その結果、最後に書かれた@mediaルールで上書きされてしまい、直したつもりが直っていなかったりする。逆に、@mediaルールで戻す必要があるパターンなどでは、上書きしてないおかげで、直したつもりが壊れてしまったりもする。
コンポーネントを意識して、個々に@mediaルールを書いていくと、同じクエリーの@mediaルールが分散してしまう。その結果、ウェブページにどのようなスタイルが当たるかの見通しが悪くなる。なんちゃってコンポーネントが相互に依存しあう現状では、不具合の原因究明に影を落とす。また、ファイルサイズもどんどん増えていく。
前者は書く時に問題が、後者は確認する時に問題が起こりやすい。それを解決するために、@mediaルールをまとめるものを使ったり作ったりしたわけだが、これはこれでCSSの詳細度における問題が常に付きまとう。CSSは順序を変えるとよく壊れるからだ。
結局のところ、@mediaルールはこういうものと捉えるしかない。でもその一部をうまく肩代わりさせることはできる。ひとつはGridやFlexboxのような標準レイアウト仕様による論理的なCSSコードへの昇華で、もうひとつがカスタム・プロパティーによる動的な値の変化を利用したCSSコードへの変更だ。と思う。一部と言ったが、多分7割くらいは置き換えた方が効率的なのではないか、と予想している。
このウェブサイトのCSSの場合は、ファイル・サイズが1/6くらい減った(12KB→10KB)。強制的に@mediaルールがまとめられる上、通常@mediaルールに書かれるセレクターがなくなるので、変数が多ければ多いほど減りそうだ。反面、カスタム・プロパティー名が長くなりがちで、参照が多ければ増えるかもしれない。ただ、極端に悪化することはないだろう。
長くなりがちなカスタム・プロパティー名から想像できるように、ここでも名前付けの問題が起きる。そういう意味では革命的なアプローチではなさそうだ。
また、慣れないとコードを行ったり来たりしなければならないので読みづらい。開発者ツールやVisual Studio Codeには頑張ってもらいたい。他のファイルに書かれたカスタム・プロパティーを補完したい。
共同開発者にはカスタム・プロパティーのみを変更させるようにすれば、CSSコードそのものには手を入れさせないようにできる。雑な変更による影響を最小限に抑えられ、破綻する確率も下がるだろう。
今のところは実証実験の初期段階だ。なんとかうまく動くし、ちょっとした変更では書き換えやすい。大きな変更でも、カスタム・プロパティーが多数存在するおかげで、部分的な再利用が可能になり、ちょっとした間違いが減る。デメリットは少ないようだ。
劇的な変更がコードに加わる割に、実際的なメリットは少ない。思想的な面での恩恵をメリットと捉えるかどうかで評価が大きく分かれそうだ。