Tailwind卒業！CSSの設計力を磨くための戦略的アプローチ

Tailwind CSSから脱却し、CSSの設計スキルを根本から見直すことにしました。メンテナンスしやすく、スケーラブルなスタイル構造を構築するための学びを記録していきます。

セマンティックなHTMLを書くとどんな感じか興味が湧いた。

私はずっとセマンティックHTMLやアクセシブルなマークアップを教えてきたし、スクリーンリーダー向けに設計されたサイトやアプリの開発にも深く携わってきた。

Tailwindの最大の問題は、HTMLとCSSについて考えるべき順序を逆転させていることだ。

HTMLはドキュメントの意味をマークアップするもの。まずそこから始めるべきで、CSSでのスタイリングはその後。その時点でスタイリングのために要素が必要ならdivやspanを使えばいい（ただし、もっと適切なものがないか先に自問すべきだ）。

その点、Tailwindは開発者を「CSSファースト」のアプローチに追い込む。まず使いたいTailwindクラスのことを考え、クラスを適用するためだけのdivをDOMに次々と放り込むことになる。

TailwindはWeb開発者としてのスキルを低下させる。というのも、将来を見据えた読みやすいHTMLとCSSを生成し、すべてのユーザーが利用できるようにし、HTML/CSSの仕様に準拠させることこそが本来持つべきスキルだからだ。しかし、ここ数年開発者はそんなことを気にしなくなっているから、Tailwindがこれほど人気なのも納得できる。Tailwindは「Reactコンポーネントを構築している」というアプローチをHTML/CSS作成に持ち込み、「divのスープ（divだらけの状態）」を望ましい結果として定着させてしまった。

Tailwindがこうしたことを全く気にしていないのは明らか。公式サイトの最初の例を見ても、divとspanばかりだ。これは新人開発者にとって最悪の教材であることが証明されているし、LLMに指示して無理やり書かせない限り出力されてしまう「divのスープ」の一因にもなっている。

私の場合、SvelteとLLMのおかげでTailwindは完全に不要になった。結局のところ、私がTailwindを使っていた主な理由は、CSSの衝突を避けるためと、（個人的には）より論理的な構文のためであって、自分で課した制約のためではなかったみたい。

Tailwindに関していつも気になるのは、推進派が使う論理のほとんどが「CSSをジュニアレベルまでしか学ばなかった」という事実に帰着することだ。Tailwindの支持者が「Tailwindがないと、巨大で整理されていないCSSファイルが際限なく膨れ上がり、不要なコードが溜まってあちこちに!importantが飛び交うことになる。だからTailwindの方が断然マシ！」と言っているのを本当によく聞く。

CSSは他の技術スキルと同じで、れっきとしたスキルだ。もし「見た目を整えるために動けばOK」という最低限のことしか学んでいなければ、すぐに自分の管理能力を超えて収集がつかなくなるのは当たり前だよ。

スケーラブルなHTMLとCSSを書くことに焦点を当てた「クリーン」なWeb開発ガイドを書いているよ: https://webdev.bryanhogan.com/

ここを見ている人の役に立つかもしれない。私はスタイリングにTailwindやその類は使わず、AstroやSvelteのようなモダンフレームワークと標準のCSSを使っている。

プロジェクトごとに以下のCSSファイルを用意しているよ:

• reset.css
• var.css
• global.css
• util.css

その他のスタイルはそのコンポーネントやレイアウト専用にスコープしている。

素晴らしい記事だね！

外部ライブラリへの依存をなくしてゼロから自分で書くのは好きだけど、Tailwindを使うのをやめないのには明確な理由がある。Tailwindは本番環境向けの最適化を提供していて、必要なCSSの最小限だけを確実に配信してくれるんだ。つまり、カラーパレットやスペーシングなどの選択肢をglobals.css等で全列挙しておいても、本番環境でそのすべてを使っているかを気にする必要がない。さらに、Next.jsのようなフレームワークを使っていれば、ビルド時に自動で最小化されるから、その心配すら不要だ。これだけでも、少なくとも私にとってはTailwindから移行しない十分な理由になる。

それに、Tailwindを使っていてインラインCSSが必要な場面で、簡単に解決できなかったこともないし、Tailwindのグリッドツールを使って異なる画面幅に対応するレスポンシブなグリッドを実装するのもとても快適だ。この記事で説明されているシナリオは、TailwindやTailwindとの組み合わせで全て解決済みだよ。確かにgrid-column-areasはネイティブにはないけど、レスポンシブなグリッドレイアウトを作る上でそれが大きな制限になると感じたことはないな。

Tailwindの最大の問題は、慣れるまでに時間がかかることだと思う。私たちはみんな「インラインCSSは悪」「グローバルスコープのCSSがベスト」などと教わって、クリーンでシンプルなHTMLに慣れきっている。だから、Tailwindを使った現実のコードを見ると、特に1行が長くて最初は読みづらく感じるんだ。結局私は使い込んで完全に慣れてしまったけど、快適に読めるようになるまでかなり時間がかかったのは覚えている。でも長期間使ってみて、結局のところTailwindの方が効率的でメンテナンスしやすく、可読性も高いという結論に達したよ。まあ、そこに至るまでにはかなり時間を要したけどね。

Julia Evansの書くものが本当に大好きだよ。

彼女は常に誠実で、弱さを見せることを恐れない姿勢で書いている。たいていの人は賢そうに見せようとして書くけれど、彼女は「全部は知らないけれど、発見したことを共有したい」というスタンスで書いているからね。会ったこともないのに、まるで愛する人たちに何かを伝えようとしているような感じがする。

彼女は前回のStrange Loop（RIP）でRandall Munroeと一緒に登壇していた。他の人たちは彼に話しかけようと待っていたけど、私は彼女と話したくて待っていたんだ。彼女がbashスクリプトをPerlで書き直すべきだっていう私のジョークは通じなかったみたいで、そこは本当に申し訳ないと思っている。

CSS Modulesは、カスケードの問題に対するもっとシンプルな解決策だよ。ユニークなクラス名を作成するから、クラスの衝突が起きない[1]。それに、Tailwindが抱える2つの大きな欠点、つまり可読性[2]とツール環境の問題がない。デバッグやChrome/FirefoxのDevToolsでのインタラクティブな実験もやりやすいんだ。

[1] https://x.com/efortis/status/1888304658080256099
[2] https://github.com/ericfortis/tailwind-eye

最近気に入っているアプローチは、SvelteやVueのスコープ付きスタイル（scoped styles）とTailwindを併用すること。こうすればテンプレートの汚れを最小限に抑えつつ、Tailwindの利便性を享受できるよ:

  <div class="counter-component">
      <button @click="count++">+</button>
      <span class="count" :data-is-even="count % 2 === 0">{{ count }}</span>
  </div>
  
  <style scoped>
  @reference "tailwindcss"
  
  .counter-component {
      @apply flex items-center gap-2;
  
      button {
          @apply bg-gray-800 text-white;
      }
  
      .count {
          @apply italic text-teal-500;
  
          &[data-is-even="true"] {
              @apply text-rose-500;
          }
      }
  }
  </style>

Tailwindには2つの大きな利点がある:

• AIの学習データにクラス情報が既に入っている
• スタイルの競合が起きない

つまり、AIが新しいスタイルを生成する際に既存のスタイルシートを参照する必要がないので、コンテキスト管理の面で非常に優れているんだ。

カスタムCSSだと、AIに既存のスタイルシートを読み込ませないと、競合するスタイルを書いたり、既に定義済みのものを再定義したりしてしまう。AIのメモリを消費するような巨大なスタイルシートを扱っている場合には、これが問題になるんだ。

いいね！私がよくやるのは、bodyのフォントサイズを10px相当（em）に設定して計算を楽にすることだよ。body { font-size: 0.625em; // 10px } としておけば、見出しを20pxにしたいときは単に h1 { font-size: 2rem } と書くだけで済むからね。