出来事の日付：2026年5月16日。 あるウェブ開発者が、複数の個人サイトをTailwind CSSから移行した経緯を記録し、その作業を従来型のスタイルシートをより意図的に整理する仕組みを構築する機会だったと説明した。この記録は、同フレームワークを普遍的に否定するものとして提示されてはいない。むしろ、長年にわたるTailwindの使用が、セマンティックHTMLとバニラCSSに持ち込める一連の手法をどのように形作ったかを説明している。

移行は、なじみのある基準から始まった。開発者は、以前のプロジェクトに定着していた前提を学び直すのではなく、`box-sizing: border-box`のグローバルな使用を含むTailwindのpreflightルールをコピーした。その後、スタイルを、コンポーネント、カラー、タイポグラフィ、ユーティリティ、そして意図的に小規模に保った基本ルール群という、異なる役割を持つファイルに分割した。

コンポーネントファイルが整理の主要単位になった。特定のページ要素に関連付けられたクラスに、その要素用のネストされたセレクターを含めることで、サイト内の無関係な部分同士が予期せず干渉するのを減らすための慣例を作ることができた。著者は、この分離はウェブコンポーネントや`@scope`などの技術によって強制されるものではなく、手続き上のものだと指摘したが、それでもこの慣例によってコードを理解しやすくなったとしている。

システムのほかの部分では、以前Tailwindが担っていた制約設定の役割を取り入れた。色は変数として一元管理し、単位や値を場当たり的に選ぶ代わりに、あらかじめ定義したフォントサイズの尺度を採用した。小規模なユーティリティ層には、スクリーンリーダー専用コンテンツのためのアクセシビリティクラスを含む、再利用可能なパターンを残した。基本層は最小限に保ち、繰り返し必要になることが明確になったルールだけをそこへ昇格させた。

再設計は、著者のレイアウトへの取り組み方も変えた。多数の要素にマージンやパディングを分散させるのではなく、余白を管理する責任を外側のレイアウトコンポーネントへ移した。`auto-fit`や名前付きグリッド領域を含む柔軟なCSS Grid機能により、ブレークポイント固有のメディアクエリーへの依存が減った。こうした機能は、フレームワークの抽象化だけを通すのではなく、プラットフォームをより直接的に扱う理由として提示された。

ネイティブCSSがインポートとネストをサポートしているため、出来上がった開発環境はビルド処理なしでも実行できる。本番環境では、有用な場合には引き続きesbuildでファイルをバンドルできると著者は述べた。より広い結論として、学習の初期段階ではTailwindが有用なデフォルト設定を提供していた一方、今回の移行はCSSを一つの技術として本格的に学ぶ手段になったという。これは個人的なワークフローの報告であり、いずれかの手法のベンチマークではないが、フレームワークの慣例が、より小規模でプロジェクト固有のデザインシステムにどのように生かされ得るかを示している。この記録はまた、フレームワークを離れることが、その教訓を捨てることを意味しないことも示している。リセット、制約付きの尺度、再利用可能なユーティリティは、その表現方法がHTMLクラスから自作のスタイルシートへ移っても、引き続き有用であり得る。