Tailwind CSSの二面性、デザインシステムを借りるということ

この雑記を書く問題意識は、Tailwind CSS に対して向けられている世の人々の不満が、Tailwind CSS がコミットしていることから外れた、お門違いの期待の押しつけになっているのではないかと感じるところにある。

ライブラリやフレームワーク、道具にはそれが作られた目的があり、果たそうとするコミットメントがある。その圏内において果たされていないコミットメントに対する不満は、それ自体の存在意義にかかわる意味を持つが、しかし利用者が一方的に寄せた期待が果たされないことに対する不満はそうではない。

念押しするまでもないと思うが、これは Tailwind CSS に対して不満を向けるべきではないという話ではまったくない。むしろ、その不満の下敷きとなっている Tailwind CSS への期待が Tailwind CSS 自体によってコミットされたものでないとしたら、不満を向けてもしょうがないのではないか、あるいは、向けようがないのではないかと考えられる可能性を検討してみようという話である。

まずは、Tailwind CSS について、その二面性についての考察からはじめる。

2 つの顔

Tailwind CSS というツールの本質は大きく 2 つ認められるだろう。そのひとつは〈pluggable な CSS ライブラリビルドツール〉としての本質、もうひとつはその上に構築される〈デザインシステムを表現する CSS ライブラリ〉としての本質だ。

pluggable な CSS ライブラリビルドツールとしての本質

〈pluggable な CSS ライブラリビルドツール〉としての本質は、Tailwind CSS の設定ファイル tailwind.config.js （以降 Tailwind コンフィグ）をもとに CSS スタイルシートを出力する部分がそれを担っている。Tailwind コンフィグをある程度触ったことがある人ならわかっていると思うが、Tailwind CSS のカスタマイズとはデフォルトで用意されたユーティリティ CSS を拡張できるというレベルの機能ではない。

Tailwind CSS がデフォルトで提供しているユーティリティ CSS は、何から何までコアプラグインと呼ばれるプリインのプラグインによって実装されている。すべてがプラグインであるということは、任意に着脱可能であるし、同じ機能を別のプラグインとして実装することもできるということを意味する。デフォルトの機能はプラグインとしてファーストパーティではあるが、機能としてツールに組み込まれたビルトインではない。すべてのプラグインを取り外し、完全にゼロから CSS ライブラリを実装することもできる。

この点において、〈pluggable な CSS ライブラリビルドツール〉としての本質は、その上に構築される CSS ライブラリの詳細についての関心を含まない。 flex や text-sm などのユーティリティクラスは、デフォルトで同梱されるコアプラグインが提供している機能であり、ビルドツールが支配する領域ではない。

このビルドツールはいわば、Tailwind コンフィグを入力とし、CSS ライブラリを出力とする関数と捉えることもできるだろう。だから、どのような CSS ライブラリが出力されるかについては、入力次第であるとしか言えないのだ。

デザインシステムを表現する CSS ライブラリとしての本質

〈デザインシステムを表現する CSS ライブラリ〉としての本質は、実際に Web サイトや Web アプリケーションの構築において利用可能な、 flex や text-sm といったユーティリティクラスが担っている。しかし上述のとおり、それは Tailwind コンフィグをもとにビルドツールが出力したものにすぎない。つまり、この本質の核はそれらのコアプラグインをまとめて調和させたデフォルトのプリセットである。そしてそのプリセットは、設計済みの、Tailwind というひとつのデザインシステムの一部である。

Tailwind がひとつのデザインシステムであるということ、それは Tailwind CSS を利用するということが、その根底にあるデザイン原則からデザイントークンからコンポーネントに至るまでその全体を借りて、そのデザインシステムの上にわれわれの Web サイトや Web アプリケーションを構築するということを意味する。

Tailwind CSS が提供する CSS ライブラリのユーティリティクラスがどれだけ汎用的であっても、それはひとつのデザインシステムであることと矛盾しない。同社が提供するTailwind UI も同じデザインシステム上で構築されたコンポーネントライブラリである。充実したドキュメンテーションもデザインシステムの一部分であり、プリセットのコンフィグが内包するコアプラグインとデフォルトのテーマも含め、その全体がひとつのデザインシステムである。

これが、 Tailwind CSS を二面性のもとに、2 つの本質を持つものとして捉える見方である。

デザインシステムを借りるということ

〈デザインシステムを借りる〉とはどういうことか。世間にライブラリが広く流通している代表的なデザインシステムとして挙げられるのは、Google の Material Design だろう。

Material is a design system created by Google to help teams build high-quality digital experiences for Android, iOS, Flutter, and the web.

ただ Material Design のボタンやフォームの UI を気に入り、その部分だけを利用しているつもりかもしれない。そうした利用もできるのは、 Material というデザインシステムの汎用性と完成度の高さによるものだろう。だが自覚的でなくとも、Material Design を採用してデザインされた Web サイトやアプリケーションは、Material というデザインシステムを借りて、その上に構築されている。

だが、借り物は借り物である以上、そのデザインシステムのオーナーシップは、われわれの側にはない。デザインシステムはそのシステムの許す範囲で拡張性を持ち、それを API として利用者に提供することもあるが、その範囲を超え出るような拡張を施そうとすれば矛盾と衝突が起こるのは必然である。典型的には、ライブラリが提供する API では表現できないカスタマイズのために、グローバル CSS を上書きすることになる。

これと同じ図式は Tailwind CSS にも当てはめられる。プリセットのコアプラグインとテーマは、その土台となるデザインシステムの許す範囲で拡張性を備えているが、その範囲を超える拡張まではサポートしきれない。借り物のデザインシステムの上で表現できるのは、そのデザインシステムが想定する範囲のものに限られる。〈デザインシステムを借りる〉というのは、表現力の限界を他者に委ねることにほかならない。

だが、Tailwind CSS が画期的であった点は、それが単にデザインシステムを表現するライブラリであるだけでなく、デザインシステムをライブラリで表現する手段もまたツールとして提供している点だ。これにより、独自のデザインシステムを持つ利用者がそれを CSS ライブラリとして表現することを容易にした。〈pluggable な CSS ライブラリビルドツール〉としての本質は、デザインシステムをライブラリにする工程そのものを普遍化させるという、ひとつの発明である。

不満の矛先

Tailwind CSS が提供するユーティリティ CSS の命名や振る舞いが気に入らないのであれば、それは〈デザインシステムを表現する CSS ライブラリ〉としての Tailwind CSS に対する不満であり、それは結局 Tailwind というデザインシステムへの不満である。だが、それは借り物のデザインシステムと、自分が表現したいデザインとの不協和音にすぎず、どちらかが正解でもなく間違っているのでもない。

表現力を他者に委ねることが省力化による喜びを生み出すかぎりは、借り物のデザインシステムは有益なものになるだろう。しかしそれが不自由による苦しみを生むのであれば、それを解消する方法はコントロールを取り戻すことしかないだろう。デザインシステムを借りることをやめ、独自のデザインシステムを構築することだ。幸いにも、Tailwind CSS はそれも容易にしている。

また、ひとつの体系として調和を図ること自体が難しい、クリエイティブかつ探索的な段階の表現においては、デザインシステムの根本的な効用であるはずの制約こそが目的を阻害するのであるから、Tailwind に限らずデザインシステムそのものがミスマッチである。どこまでの表現力が必要になるかわからないうちにデザインシステムを利用するのは賭けであると言えよう。