デザインシステムに .btn-sm .btn-md .btn-lg の3つがあるとします。ここに共通の余白を当てたくなったとき、あなたはどう書きますか。
3つ並べて列挙するか、HTML 側に .btn を足して回るか、[class^="btn-"] のような属性セレクタで済ませるか。どれを選んでも、半年後に誰かが .btn-xs を足した瞬間に破綻します。 列挙は更新漏れし、HTML への追記は既存テンプレート全部に手が入り、属性セレクタは思わぬ要素に当たります。
2026年8月にベルリンで開かれた CSS ワーキンググループの会合で、この用途のための クラス接頭辞セレクタ .prefix-* を Selectors Level 5 に追加することが決まりました。Lea Verou が2024年に提案していたものです。
いまの3つの書き方が、それぞれ何を失っているか
まず現状を整理します。よく使われる回避策は3つですが、失っているものが違います。
列挙する。 .btn-sm, .btn-md, .btn-lg { ... } と書く方法です。動作は確実ですが、バリエーションを増やすたびに CSS 側の全箇所を更新する義務が発生します。新しいサイズを足した人がスタイルシートの何行目を直すべきか分からず、当たっていないことに気づかないまま公開されます。
HTML にベースクラスを足す。 class="btn btn-sm" の形にする方法です。BEM 系の設計ではこれが自然ですが、既存サイトの改修で採ると、テンプレート・CMS の出力・過去記事の本文中に埋まった HTML まで手を入れることになります。マークアップの量も増えます。
属性セレクタで書く。 ここが一番誤解されています。[class^="btn-"] は class 属性の文字列全体が btn- で始まる場合にしか当たりません。 class="card btn-sm" は対象外です。だから実務では [class*=" btn-"] を併記することになり、今度は class="icon-btn-sm" のような無関係なクラスにも当たります。
| 書き方 | 壊れ方 |
|---|---|
| 列挙 | バリエーション追加時に更新漏れする |
| ベースクラス追記 | HTML の改修範囲が既存テンプレート全体に広がる |
| 属性セレクタ | 先頭一致は複数クラスで外れ、部分一致は無関係なクラスを巻き込む |
なお、問題は詳細度ではありません。 属性セレクタの詳細度は (0,1,0) でクラスセレクタと同じです。困るのは、読んだ人が意図を推測できないことと、マッチ範囲が事故ることのほうです。
決まった仕様と、まだ決まっていないこと
.prefix-* は、末尾の -* が「ここから先はハイフン区切りの任意の続き」を表します。.btn-* と書けば .btn-sm にも .btn-lg にも当たり、あとから増えた .btn-xs にも自動的に当たります。HTML に何も足す必要はありません。
詳細度については、仕様上は明示されていないもののクラスセレクタと同じ (0,1,0) になると読める書き方になっています。ここは実装が出るまで確定として扱わないほうが安全です。
構文に -* が選ばれたのには先があります。ワーキンググループは CSS 全体でワイルドカードの書き方を揃える方向で議論しており、将来的に [data-*] のような属性名のワイルドカードや、my-framework-* のようなカスタム要素名への拡張に同じ形を再利用できるようにするためです。
そして最も重要な点として、ブラウザ実装はまだ1つもありません。 決まったのは仕様に入れることであり、明日書けるようになる話ではありません。
実装を待たずに、今日決められること
実装が無いなら何もできないかというと、逆です。この仕様が効くかどうかは、クラス名の付け方で先に決まります。 そして命名規約は今日から変えられます。
- 区切りをハイフンに統一する。
.btnSmや.btn_smは接頭辞セレクタの対象外です。キャメルケースとスネークケースが混在しているプロジェクトは、ここで寄せておくかどうかで将来使えるかが決まります。 - 接頭辞を「意味の単位」に合わせる。
.btn-smと.btn-primaryが同じ接頭辞を共有していると、サイズにだけ当てたいときに一括指定できません。サイズ系を.btn-size-smにするか、そもそも接頭辞を分けるかを設計の段階で決めます。 - 接頭辞の衝突を潰す。
.card-*と.card-header-*のように、片方がもう片方の接頭辞になっている状態は、一括指定したときに意図しない範囲まで当たります。命名の一覧を作って、包含関係になっているものを洗い出しておいてください。
Tailwind や Bootstrap のように生成されたユーティリティクラスを使っている場合、この規約はフレームワーク側がすでに決めています。自前のクラスとフレームワークのクラスが混ざる構成での考え方はTailwind とネイティブ CSS の使い分けに整理しました。
引き渡す側が書いておくこと
制作を請けてサイトを納品する立場では、命名規約はドキュメントに残らないと消えます。次に触る人が別の会社であればなおさらです。
最低限、接頭辞の一覧と、それぞれが何のバリエーションを表すかの対応表を1枚残してください。これがあれば、後任が .btn-xs を足すときに規約から外れずに済みます。デザインシステムの引き渡しで何を成果物に含めるかはAI が読める形でデザインシステムを渡すでも扱っています。
もう1つ、現在 [class^=] や [class*=] を使っている箇所を洗い出して、コメントを添えておくことをおすすめします。将来 .prefix-* が実装されたときに置き換える候補が、その場で分かる状態になります。
次にやること
まず、手元のプロジェクトで [class^= と [class*= を検索してください。 ヒットした箇所が、この仕様が入ったときに真っ先に置き換えられる場所です。件数がゼロなら急ぐ理由はありませんし、多いなら命名規約の見直しが先です。
そのうえで、クラス名の区切り文字が統一されているかを確認してください。 ここが混在していると、仕様が実装された日に自分たちだけ使えません。
Web サイトの CSS 設計、デザインシステムの命名規約整備、既存サイトのリニューアルについては、グリームハブの HP 制作・リニューアル相談で承っています。サイトの規模と現在の構成によって進め方が変わるため、個別にご相談ください。お問い合わせからどうぞ。
