ハクソク

世界を動かす技術を、日本語で。

Tailwindから離れ、CSSの構造を学ぶ

9日前原文(jvns.ca)

概要

  • Tailwind から バニラCSS ＋セマンティックHTMLへの移行体験談
  • Tailwindで学んだCSS設計の知見と再実装の工夫
  • 独自の色管理やコンポーネント設計、グリッドによるレスポンシブ対応
  • Tailwind依存から脱却した理由とCSS技術への再評価
  • 今後学びたいCSSの新機能や、CSSコミュニティへの感謝

TailwindからバニラCSSへの移行と学び

  • 8年前、 Tailwind を発見し、CSS設計が分からない中で混乱よりもTailwindを選択
  • Tailwindは小規模サイト制作に役立ち、多くの知見を得るきっかけ
  • 最近、複数サイトを バニラCSS＋セマンティックHTML へ移行し、学びと楽しさを実感
  • フロントエンド専業ではなく、CSS学習は断続的に進行

Tailwindで学んだCSS設計の本質

  • CSSコードベースは レイアウト・フォント・色・共通コンポーネント など多要素で構成
  • 各要素の管理指針やシステムがないと混乱を招く
  • Tailwindのシステム（リセット、カラーパレット、フォントスケール等）が有用
  • 好きなシステムは 自作CSS設計 にも模倣・応用可能

CSS設計の各ポイント

1. Reset（リセット）

  • Tailwindのpreflight styles （リセットCSS）を流用
    • 例：* { box-sizing: border-box; }
  • 長年リセットCSSに慣れていて、無意識に依存している部分も多い

2. コンポーネント設計

  • CSSを コンポーネント単位 で整理
    • 各コンポーネントに 一意のクラス名 を付与
    • 他コンポーネントのCSSを上書きしない運用
    • 各コンポーネントごとにCSSファイルを分割
  • 編集時の影響範囲が明確になり、メンテナンス性向上

3. 色管理

  • colours.css で全色をCSS変数で一元管理
  • サイトで使う色は全てこのファイルに明記
    • 例：--pink: #fea0c2;

4. フォントサイズ

  • Tailwind同様、 フォントサイズ・行間 をCSS変数で定義
    • 例：--size-lg: 1.125rem;
  • 変数で管理することで、単位や値の迷いを解消

5. ユーティリティクラス

  • 複数コンポーネントで使うクラス （例：.sr-only）をutilityとして管理
  • 必要最小限に留め、変更は慎重に

6. ベーススタイル

  • サイト全体に適用する 最小限の共通スタイル を設定
    • 例：sectionの中央カラム幅や、aタグの色指定
  • 基本はベーススタイルを極力少なくし、共通化したいものだけ移動

7. スペーシング（余白管理）

  • 外側のレイアウトコンポーネント が余白を決める設計にシフト
    • 例：section > *+* { margin-top: 1rem; }
  • Tailwind時代の行き当たりばったりな余白設定からの脱却

8. レスポンシブデザイン

  • Tailwindの メディアクエリ多用 から、 CSS Grid 中心の柔軟なレイアウトへ
    • 例：grid-template-columns: repeat(auto-fit, minmax(min(100%, 400px), max-content));
  • grid-template-areas など、Tailwindでは難しい機能も活用

9. ビルドシステム

  • 開発時は CSSのimportやネスト を活用し、ビルド不要
  • 本番用には esbuild でバンドル
    • 例：esbuild style.css --bundle ... --outfile=/tmp/out.css
  • esbuildはWeb標準準拠＆Goバイナリで導入が容易

Tailwindから離れた理由

  • Tailwindが ビルドシステム依存 になり、v2を長年使い続ける状況
  • ビルドせずに使うと 巨大なCSSファイル が生成され、非効率
  • CSSスキルが向上し、 Tailwindの制約 が物足りなくなった
  • プロジェクト内で バニラCSSとTailwindが混在 し、保守が困難
  • セマンティックHTML での開発体験を試したくなった

今後学びたいCSS機能

  • @layer （カスケード管理）
  • @scope （スコープ付きスタイル）
  • container queries （コンテナクエリ）
  • subgrid （サブグリッド）

CSSに対する姿勢の変化とTailwind批判

  • CSSは「簡単」ではなく 本質的に難しい問題 を解決する技術
  • Tailwindの普及が CSSの専門性の価値低下 につながる懸念
  • CSS技術を真剣に学び、 自分の技術として尊重
  • 最新CSS機能の進化と、学習による成長体験
  • LLM時代 における人間の専門性重視の重要性

コミュニティへの感謝

  • wizardzines.comのCSS設計者 Melody Starling への謝辞
  • CSS TricksやSmashing Magazineなど、 CSSコミュニティの情報発信 への感謝

Hackerたちの意見

もっとセマンティックなHTMLを書くとどんな感じになるのか気になったんだ。セマンティックHTMLやアクセシブルなマークアップを長いこと教えてきたし、スクリーンリーダー向けにデザインされたサイトやアプリでたくさん仕事してきた。Tailwindの最大の問題は、HTMLとCSSについて考える順序を逆にしちゃうことだよ。HTMLは文書の意味をマークアップするもので、そこから始めるべきなんだ。その後にCSSでスタイルを付ける。もしその時にスタイリングのために追加の要素が必要なら、divやspanを使うかもしれないけど、まずはもっと良い方法がないか自問自答すべきだよ。Tailwindは代わりに、開発者をCSSファーストのアプローチに押し込んじゃう。Tailwindのクラスを考えて、それからクラスをぶら下げるためだけにまた別のdivをDOMに追加することになる。Tailwindは、スキルの観点から見ると、ウェブ開発者としての能力を低下させるよ。スキルの一部は、将来にわたって読みやすいHTMLとCSSを作成することだから、すべてのユーザーが使えるようにし、一般的にHTMLとCSSの仕様に合致するべきなんだ。でも、開発者たちは何年もそれを気にしていなかったから、Tailwindが人気になったのも理解できる。Tailwindは「Reactコンポーネントを作っている」アプローチに対する解決策を提供し、divスープを望ましい結果として codify しちゃった。Tailwindはこれらのことに全く気を使っていないのが明らかだよ。Tailwindのウェブサイトの最初の例は、ただのdivとspanばかり。新しい開発者にとってはひどい教育になっていて、LLMが出力するdivスープに寄与している。そうならないように促したり頼んだりしない限りね。

└

あなたの言ってることは間違ってないし、ほぼ同意するよ。多くのサイトがdivスープになってるのを見ると、内心死にそうになる。でも、CSSの重要な部分をHTMLに少し統合できる価値はあると思う。どこまでが許容範囲かは確かに議論の余地があるけど（私には答えがない）、Tailwindを使ったサイトの方が、Tailwindを使う前のサイトよりも読みやすいことが多いんだ。なぜなら、スタイリングを考えるために別のファイルを開く必要がないから。大きなものに関しては、2つ目のファイルがあると便利だけど、HTMLの中でスタイルを調整できるのはすごくいい。Tailwindは確かにCSSファイルを無視する方向に導くけど（またはすごくミニマルに保つ）、それはアンチパターンになりつつあるのに同意するよ。

└

私も同意するけど、あなたのアプローチには「純粋さ/正しさの追求」があると思う。それは私がずっと手放してきたものだ。HTML/CSS/JSのごちゃごちゃは、ブラウザをターゲットにするために必要な悪だと思ってる。私にとっては「ただのプレゼンテーション層」なんだ。仕事では、データベースのスキーマやバックエンドのビジネスロジックの正しさにもっと重きを置いてる。ごちゃごちゃしたプレゼンテーション層に関しては、できるだけ少なく書くことを好むけど、ある程度メンテナブルなコードにはなるようにしてる。だから、Tailwindはすごく合ってるんだ。LLMはそれをうまく書いてくれるし、新しい開発者もすぐに理解できるし、後でコードを読み返したり調整したりするのも簡単だよ。Tailwindプロジェクトが新しい開発者にとってHTML/CSSを学ぶ最良の方法ではないことには100%同意する。でも、私は新しい開発者には素晴らしいデータベーススキーマや直感的なAPI、テスト可能なビジネスロジックに集中してほしいと思ってる。HTML/CSSのごちゃごちゃに手を出すのは、人間の注意を最も効果的に使う場所ではないと思うし、開発者がより良い開発者になるためのスキルを身につける場所でもない。

└

いくつかの反論を挙げると、マークアップとスタイルを別々に扱うのは原則的には素晴らしいけど、特定のことには追加のマークアップが常に必要になる。これは2000年代初頭から知っていたことだよ。Tailwind自体には、適切なHTMLタグの代わりにdivやspanを使わざるを得ないという強制力はない。ドキュメントとインターフェースは異なるもので、Tailwindはインターフェースにはもっと理にかなっている。インターフェースにはTailwindを使い、他のコンテンツにはスコープ付きのHTMLセレクタを使うことができる。Tailwindは、複雑なCSSコードベースを書くのに比べて約4倍速く、ほとんどオーバーヘッドがない。これについてどう思おうと、これは常にその利点になる。

└

こういう風に開発するための良い学びのソースはどこですか？アクセシブルなHTML/CSS構造を作るための。EDIT: 無視してください。プロフィールにいくつかリンクがあるのが見えます。チェックしてみます。

└

HTMLはドキュメントの意味をマークアップすることだよ。そこから始めるべきだね。それからCSSでスタイリングする。これが俺のやり方。HTMLを生成するコードを書いて、まずはNetscape Navigator 1.0の悪夢みたいに画面に全コンテンツが見えるようにしてから、戻ってスタイルを加えて見栄えを良くする。難しくはないよ。ただ考えと計画が必要なだけ。俺が見つけた一番の計画ツールは鉛筆と方眼紙で、今流行りのウェブデザインSaaSじゃないんだ。ただ、最近は良い鉛筆削りを見つけるのが意外と難しい。

└

Tailwindは開発者をCSSファーストアプローチに押し込む。欲しいTailwindクラスを考えて、クラスを掛けるための要素を持つためだけにDOMにまた別のdivを追加する。正直、どこにでもdivを置くのはTailwindが登場するずっと前から始まってるよ。これはReactとCSS in JSの混乱のせいだと思ってる。

└

Tailwindを使うことがアクセシビリティに対する本質的な妥協をもたらすわけじゃないよ。どうしてそんな結論に至ったの？彼らのコンポーネントライブラリを見ると、aria属性を含める作業もしてくれてるよ。https://tailwindcss.com/plus/ui-blocks/marketing/sections/pr...（見つけた無料コードの最初の例）。ランディングページの話をしてるわけじゃなくて、デジタルパンフレットみたいなものであれば、いつもマークアップから始めて、その上にCSSクラスを追加するよ。

└

なんか不公平に物事を混同して、Tailwindのせいで理解不足や配慮不足になってるみたいに言ってるけど、それは開発者自身の問題だよ。Tailwindを使ったからって、アクセスできないアプリや「ダイバースープ」なアプリを作らなきゃいけないわけじゃないし。確かにTailwindを使いこなせないこともあるけど、それはどんなツールにも言えること。私は約20年間CSSを書いてきて、CSS、Less、SASS/SCSS、Stylus、PostCSSなどを使いこなしてるけど、ここ数年Tailwindを選んだのは、より堅牢なアプリケーションスタイリングができるからなんだ。Tailwindは、変わるスタイルやクラスの抽象化に過剰な時間をかける必要をなくしてくれる。影響を受けるマークアップにスタイルを直接入れることで、認知的負担が減って、意図せずスタイルに影響を与える緩いセレクタを防ぎ、デバッグも楽になる。カスタムCSSフレームワークを使ったコードベースに飛び込むのは、Tailwindのコードベースよりも複雑で脆弱になることが多いし、シンプルなサイトやアプリ以外ではそうなる。さらに、タイプ、色、サイズのスケールを一貫して持てるし、バンドルサイズも小さくできる。Tailwindを知っている開発者にとっての一貫性や、非常に堅牢なエコシステム（だからLLMもよく知ってる）を考えると、Tailwindは多くのチームにとって本当に素晴らしい選択肢だよ。Tailwindはほとんどのツールと同じで、使う人によって良くも悪くもなるんだ。

└

あなたのコメント、すごく新鮮だと思う。25年前、Microsoft Frontpageがすごくシンプルなワード文書（あまりフォーマットがないやつ）を、全く解読不可能なHTMLのゴチャゴチャに変えてしまったのには驚いたよ。ほんの少しの変換で、その文書のテキストをメモ帳に貼り付けて、いくつかの見出しタグを追加するだけで、同じ表示結果が得られるのに、ずっと理解しやすいソースになるんだ。CSSにはHTMLコンテンツを簡素化する大きな可能性があったけど、世界はそれを阻止しようと必死だった。今では、シンプルなウェブページのために何メガバイトもあるモンスターができてる（グラフィックを数える前から）。

└

Tailwindに対する批判には同意するよ。個人的には、良い批判には代わりに何をすべきか、あるいは修正や改善のパターンについての意見が必要だと思う。Tailwindがここまで人気になった理由があるし、これはHTMLやCSSがそのタスクに対して提供するもののギャップや、そのアプローチの難しさを際立たせてる。批判の中でこれを見失ってはいけないね。もう一つの観察として、技術的なユーザーインターフェースの決定や議論では、今日の主要なユーザーインターフェースレンダリングメカニズムに固有のツリーデータ構造に重点が置かれていないことがある。ツリー構造であることには固有の利点と欠点があって、開発者もフレームワークもそれを活かしていない。ツリーとして考えると、特定の制約や命名規則を追加することで、HTMLとCSSだけでより芸術的な表現ができるようになるけど、Tailwindや他のフレームワークがそれを奨励しているのは見たことがないよ。

私にとって、SvelteとLLMはTailwindの必要性を完全に取り除いてくれた。結局、CSSの衝突を避けるためと、より論理的な構文を求めて使っていたことが分かった。自己制約ではなくてね。

└

SvelteがTailwindに対する君のスタンスにどう影響したの？

Tailwindの急速な普及は、今や主に分散クラウドシステムやエージェントの退屈な作業をしている私を嬉しくさせてくれる。

Tailwindについていつも気になるのは、その支持者たちの主張がほぼ「私はCSSをジュニアレベル以上に学んでいない」ということに集約されることだ。Tailwindの支持者が「Tailwindがなければ、常に制御不能に成長し、古いものがたくさん詰まった大きな無秩序なCSSファイルができてしまう！Tailwindの方がずっと良い！」と言うのは本当に一般的だ。CSSは他の技術スキルと同じようにスキルなんだ。もしあなたが、見た目が正しいものを作るために最低限のことだけを学んでいるなら、あなたの野心はすぐに整理する能力を超えてしまうよ。

└

コードベースを見たとき、Tailwindって純粋なCSSのコードベースを学ぶよりも理解しやすくない？それがTailwindがスケールしやすいっていう主張の一部なんじゃない？

└

それ以上にひどいよ。Tailwindに関する一般的な議論は、CSSがどう機能するかについての完全な無知から来てるし、他の文脈では開発者が崇拝するようなガイドライン（つまり「繰り返さない」）を無視してる。TailwindとCSSについて誰かと話していて、「カスケーディング」が何を意味するのかも知らないし、スタイルシートの文脈でその概念が役立つかもしれないことすら考えたことがないって気づくのは本当にイライラする。

└

SQLをラップするライブラリを使ってる人たちにも同じことが言えるんじゃない？

└

これがTailwindの価値だよ。CSSを学ばなくても、いい結果が得られる。学ぶメリットは微々たるものだね。

└

個人的には、Tailwindを使ってみた結果、プロのコードベースで素のCSSにこだわる必要はないと思うし、単純なDOM操作にこだわる必要もないかな。Tailwindのクラスは、他の似たようなツールよりもDSLっぽくない気がする。でも、職場では純粋主義にならないつもりだけど、君の意見には賛成だし、君の指摘を超えた層も感じてる。これらに過度に依存すると、HTMLをジュニアレベル以上で学ばなくなるんだ。クラスベースのCSSに頼りすぎて、セマンティックな要素が何かを学ぶことなく``を使うのが簡単になっちゃう。それが、ブラウザでネイティブに処理できる動作を定義するためにたくさんのJavaScriptを書くような他の悪習にもつながる。個人的な皮肉として、雇用主がCSSを直接書くように求めたことがないから、実際にCSSが上手くなったのはJavaScriptのおかげなんだ。特に、Webスクレイピングを始めてからセレクタのロジックの理解がかなり向上した。

└

経験豊富なTailwind支持者たちは、また別のオンラインの炎上に巻き込まれるより、もっと良いことをしてると思うよ :) 90年代からたくさんCSSをやってきたけど、Tailwindを見てからは主に生のCSSを避けるようにしてる。ある意味、ひとつの混乱を別の混乱に交換してる感じだね。個人的には、複数のファイルにまたがるスタイルの重複や矛盾を理解しようとするより、ローカライズされたクラスのスープを扱う方がマシだと思う。どちらもクリーンに実装できるけど、CSSの混乱を片付けるより、Tailwindの混乱を片付ける方がずっと楽だし、開発プロセス全体がもっと楽しいと感じるよ。

└

あなたの言うことは間違ってないけど、私が関わった「フルスタック」開発者の圧倒的多数は、CSSを基本的なレベルでしか知らなくて、深く学ぶことにあまり興味がないんだ。私自身、20年以上プログラミングをしていて、ウェブ開発はほぼ15年やってるけど、CSSをしっかり学ぶモチベーションが見つからない。追いつかなきゃいけない技術スキルが多すぎて、CSSは優先順位がかなり低いんだ。専門家に頼りたいけど、企業は専任のフロントエンド開発者を雇うことに消極的だね。

「クリーン」なウェブ開発ガイドを書いてるんだけど、HTMLとCSSをスケーラブルに書くことに焦点を当ててるんだ。https://webdev.bryanhogan.com/ ここにいる人たちに役立つかも。スタイリングにはTailwindとかは使ってなくて、AstroやSvelteみたいなモダンなフレームワークを使ったCSSだけだよ。プロジェクトごとに以下のCSSファイルを用意してる：

  • reset.css
  • var.css
  • global.css
  • util.css 他のスタイリングは、その特定のコンポーネントやレイアウトにスコープされてる。
└

JavaScriptフレームワークを使うのは、全体の目的を台無しにするんじゃない？

Tailwindは関心の分離のルールを破るアンチパターンだと思う。こんなに人気になったのが信じられない。

ああ、ついに振り子が元のCSSに戻ってきたのかな。

いい記事だね！外部ライブラリへの依存をなくして、自分でゼロから解決策を書くのが好きなんだけど、Tailwindに関してはそうしない理由があるんだ。彼らは、必要な最小限のCSS以上を出荷しないようにするためのプロダクション最適化を提供してる。これにより、色やスペース、その他のオプションのパレットをglobals.cssや他の場所で完全に列挙できるし、プロダクションでそれらのバリアントを使っているかどうかを心配する必要がない。さらに、Next.jsのようなフレームワーク内で作業している場合、この最小化ステップはビルド時に自動的に行われるから、心配する必要すらない。これだけでも、少なくとも私にとってはTailwindから移行しない理由としては十分だよ。それに、Tailwindを使ってインラインCSSを使う際に、特に難しい制約を感じたことはないし、Tailwindのグリッドツールを使って異なる画面幅に対応する素晴らしいレスポンシブグリッドを実装するのも簡単だった。この記事に書かれているシナリオは、TailwindやTailwind-CSSの組み合わせで解決できたけど、確かにグリッドカラムエリアはネイティブにはないね。でも、レスポンシブグリッドレイアウトを作る上でそれが大きな制約だとは感じていないよ。Tailwindの最大の問題は、単純に読むのに慣れるまで時間がかかることだと思う。みんなインラインCSSはダメ、グローバルスコープのCSSがベストだって学ぶし、クリーンでシンプルなHTMLを見るのに慣れてる。その後、Tailwindを使った実際のコードを見ると、最初はすごく読みづらく感じるし、特に行が長いからね。私はもう長い間使ってきたから、その見た目に完全に慣れちゃったけど、Tailwindを読むのに慣れるまでかなり時間がかかったのを覚えてる。長い時間が経った後、私にとってTailwindは本当に効率的でメンテナブルで、さらに読みやすいと結論づけたけど、それにはかなりの時間がかかったよ。

Julia Evansの文章が本当に大好き！彼女は脆弱性と誠実さから書いてる。ほとんどの人は賢く見せようとして書くけど、彼女は「全部知ってるわけじゃないけど、私が発見したことを共有したい」と言いたいから書いてる気がする。彼女は直接知らない人たちに愛を持って何かを共有したいって感じがする。彼女は前回のStrange LoopでRandall Munroeと一緒に話してた（RIP）。何人かの人は彼と話すために待ってたけど、私は彼女と話すために待ってた。彼女に「bashスクリプトをperlに書き直すべきだ」ってジョークを言ったけど、彼女がそれを理解してくれなかったと思う。それについては本当にごめん。

CSS Modulesは、カスケーディングの問題を解決するシンプルな方法だよ。ユニークなクラス名を作るから、クラスがぶつかることもないしね。[1] それに、TWの主な欠点である可読性[2]やツールの使い勝手がないのもいいところ。デバッグやChromeやFirefoxのDevToolsでインタラクティブに試すためのツールも必要ないし。