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

あなたの言ってることは間違ってないし、ほぼ同意するよ。多くのサイトが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や他のフレームワークがそれを奨励しているのは見たことがないよ。