このウェブサイトにはクラスがありません

2025年9月18日原文(aaadaaam.com)

概要

CSSリセットの存在を否定し、 要素自体のデフォルト活用 を推奨
クラス排除 に挑戦し、HTMLタグやカスタム属性でスタイリングを管理
セマンティックなマークアップ とアクセシビリティの向上
コンテキストスタイルやカスタム要素利用のメリット・課題
大規模プロジェクトへの適用には慎重な検討が必要

CSSリセットという幻想と、要素本来の力

CSSリセットは 万能ではない という認識
ブラウザ組み込み要素 を「カスタム要素の“カスタム”抜き」と捉える視点
要素本来のデフォルト を積極活用する設計思想

クラス排除への挑戦

クラス完全廃止 のためのサイトリファクタリングを実施
CSS Zen Garden時代 以来のクラスレスアプローチへの回帰
現代HTML/CSS での制約が創造性を刺激

スタイル構造とその見直し

CSSは base, components, utilities の3レイヤー構成
- base：タグセレクタ中心
- components：クラス依存を廃止し要素や属性で管理
- utilities：完全削除
セマンティック要素 の利用増加
共通パターン抽出 による要素デフォルトの強化
コンテキストスタイル （入れ子や:where(), :has()等）の活用

コンテキストスタイルの落とし穴

過剰なコンテキスト指定で セレクタが複雑化
例：li:has( > a + p) のような 深い入れ子と複雑な条件
可読性・保守性 の低下リスク

カスタム要素と属性による新たなパターン

Web Components的発想 でカスタム要素名・属性を活用
BEMのmodifier的用途 もカスタム属性で置換可能
例：note-pad, random-pattern などの カスタムタグ と属性
- [shape-type="1"] などでバリエーション管理
data-属性以外の 任意のダッシュ区切り属性 も利用可能

クラス再発明の議論とその違い

「クラスの再発明」との指摘もあるが
- カスタム要素名＋属性 は将来Web Components化も容易
- タグと属性の組み合わせ で一貫したシステム形成

メリットと課題

CSS量削減（ 全体で約5KB に）
アクセシビリティ向上 と クリーンなマークアップ
著者側の設計・計画負担 は増加
大規模・多人数開発では 推奨しづらい
セマンティック価値喪失や余計なラッパー の問題も

今後の展望と葛藤

個人サイトには満足 だが、万能解ではないという認識
クラスの有用性に 疑問を持ち始めた 心境の変化
今後の制作スタイルに 長期的な影響 を及ぼす予感

例外事項

11tyのシンタックスハイライト のみクラス利用を継続
- クライアントサイドJS導入や著者体験の悪化を避けるため
- 100%クラスレス化は未達成

このアプローチは HTMLタグと属性の本来の力 を最大限に引き出し、 CSS設計思想の再考 を促すものです。しかし、 全てのプロジェクトに適用できる万能策ではない ことも明らかです。

Hackerたちの意見

かなりの量のCSSを削除したよ（今はサイト全体で約5KBのCSS）。これはその記事の単一ページのサイズの約2%で、特にウェブサイトのメンテナンスや追加を考えると、ほんとに些細な量だね。

└

5KBはほんとに些細なことだね。実際にどれくらい削除されたかは言ってないし、もしかしたら200KBかも？誰にもわからないよね。

└

確かに、そのページは2つの巨大なフォントを読み込んでるね。多くのブログはシステムフォントを使ってるから、サイトのサイズを減らしたいならこのアドバイスは一般的に役立つよ。フォントなしでの合計ペイロードは約12kbだから、CSSを5kbに減らすのはかなり大きなことだよ。フォントがなければ、サイト全体は最初のTCPパケットで配信できるかも。

└

CSSファイルで「public,max-age=0,must-revalidate」をやってなかったら、さらに無関係になってたね。

最近、アプリのフロントエンドを作るために似たような道を辿ったんだ。最初はうまくいって、CSSの最近のアップデートについてたくさん学んだよ。ほんと、進化したよね。カスケードレイヤー、ネスティング、:hasセレクタがあれば、ビューの書き方が劇的に良くなる。ブログや独特なドキュメント感のあるアプリにはいい解決策だけど、それ以上のことには制限が多くて脆いと感じた。やっぱりコンポーネントとTailwindに戻るよ。

└

CSSが制限が多すぎるって文句を言ってる人は聞いたことがないよ。むしろ逆だと思う。

└

このコメント、全然理解できないんだけど。CSSが制限的だって言ってるのに、クラスを使ってCSSを適用するだけのTailwindが解放的だって？Tailwindは実際、もっといろんなことを複雑にするよ。例えば、バリアントを指定しなきゃいけないとき、tw-variantsをインストールして、いろんなボタンを作るためにJavaScriptを書く羽目になる。shadcn-uiみたいな大きなコンポーネントライブラリにはいいかもしれないけど、シンプルさを求めるなら、button .errorやbutton .secondaryみたいな純粋なCSSの方がいいと思う。（もちろん、あのブロックの中で@applyを使えばいいってのは分かってるけど、そうするとTailwindのメリットって何なの？）

└

Tailwindの炎上戦争に自分から飛び込んじゃったみたいだ。もっと考えるべきだったな。TW+TSXは、俺にとってUIを書く最も生産的な方法で、もう5年もそうしてる。気に入らないなら使わなければいいけど、お願いだから放っておいてくれ。

まあ、HTMLは典型的なドキュメントを記述するための一般的な言語であるべきだったんだ。ほとんどのウェブサイトはデフォルトの要素以上は必要ないよね。外から見ると、ウェブ開発者がウェブサイトを複雑にすることと、シンプルな原則を再発見することの間で行ったり来たりしているのが不思議だよ。

└

ごめん、でも複雑さを求めてるのは開発者じゃないよ。ユーザーやデザイナーは、たくさんのアニメーションで「雰囲気」を出すために、スナッピーなインタラクティブUIを求めてる。開発者は、2003年からそのまま出てきたようなウェブサイトでも全然大丈夫だと思うよ（今まで見てきた言語のドキュメントページを考えるとね）。

右クリック -> ソースを表示。見つけた "<span class=..." — え？ページを読んでみて。フッターには「99%までしか行けなかった。11tyの構文ハイライトプラグインを使っていて、スタイリングにはクラスを使ってる。」って書いてある。

└

それは妥当だと思う。セマンティック情報ではないし（ある意味ではそうかもしれないけど、スクリーンリーダーにそう表示させたくはないよね）、だからクラスはそこで問題ないよ。

Hacker Newsで議論の続きを見る

ハクソク