CSSの隠れた名脇役:属性値ハイフンリストセレクタ `[attr|=val]` を使いこなす
フロントエンドの現場で、特定のクラス名や属性値を条件にスタイルを当てる際、何を思い浮かべますか?おそらく、多くの人は `[class^=”btn-“]` のような前方一致セレクタを真っ先に選ぶはずです。
しかし、もしあなたが「言語コード」や「特定の命名規則に基づいたモジュール」をスマートに管理したいなら、`[attr|=val]`(属性値ハイフンリストセレクタ)という、少し渋いけれど非常に強力な武器を知っておくべきです。
今日は、この「ハイフンリストセレクタ」がなぜ実務で重宝されるのか、そしてなぜそれが「ただの前方一致」とは決定的に違うのかを、現場の視点から紐解いていきましょう。
—
1. `[attr|=val]` とは何か?:言語と命名の守護神
このセレクタは、指定した属性値が「その値そのもの」か、あるいは「その値にハイフンが続いて始まるもの」にマッチします。
例えば `[lang|=”en”]` と書くと、以下の要素にマッチします。
- `
` (完全一致)
- `
` (ハイフン区切りで続く)- `
` (同上)一方で、`
` や `` (アンダースコア)にはマッチしません。ここが、前方一致セレクタ `[attr^=”val”]` との決定的な違いです。2. なぜ実務でこれを選ぶべきなのか?
前方一致セレクタ `[attr^=”val”]` は、良くも悪くも「文字列の先頭が一致していれば何でもいい」という乱暴な側面があります。例えば `class=”button-primary”` と `class=”button-base”` を両方拾ってしまう。
しかし、`[attr|=val]` は「ハイフン(-)という境界線」を明確に意識した設計です。
これは特に、国際化対応(i18n)や、BEMライクな命名規則において、「意図しない文字列の拾い上げ」を防ぐための強力なセーフガードになります。ブラウザのレンダリングエンジン側でも、このセレクタは「単なる文字列操作」ではなく「トークンベースの境界判定」として処理されるため、CSSOM(CSS Object Model)構築時の解釈が非常に論理的です。
3. 実践:現場で使えるコード例
実際に、言語ごとの装飾や、モジュールのバリエーション管理に活用するパターンを見てみましょう。
/ 1. 国際化対応:ロケールごとのフォント設定 /
/ en, en-US, en-GB などにマッチする /
[lang|=”en”] {
font-family: ‘Segoe UI’, sans-serif;
}/ 2. デザインシステムのバリエーション管理 /
/
.btn-primary-large や .btn-primary-small など、
‘btn-primary’ という基幹を持つクラスだけをピンポイントで狙う
/
[class|=”btn-primary”] {
background-color: #007bff;
color: #fff;
border: 1px solid #0056b3;
/
注意:[class|=”val”]はクラスリスト全体を判定します。
“btn-primary-large” のような単一クラス名には効きますが、
“btn btn-primary” のようにスペース区切りの場合は
別のセレクタ戦略が必要になるため、命名規則は統一しておきましょう。
/
}4. シニアからのアドバイス:運用時の注意点
このセレクタを使いこなす上で、一つだけ覚えておいてほしいことがあります。それは、「ハイフン」という記号の意味をチーム内で定義することです。
`[attr|=val]` は「ハイフン(U+002D)そのもの」を境界として判定します。もしあなたのプロジェクトの命名規則が `button_primary` のようにアンダースコアを使っている場合、このセレクタは役に立ちません。
- 推奨: BEMを採用し、ブロックと要素、モディファイアをハイフンで区切る命名規則(例: `c-button-large`)を徹底しているなら、このセレクタは最強のツールになります。
- 非推奨: 命名規則が混在しているレガシーな環境で、このセレクタを安易に導入すると、「なぜかスタイルが適用されない」というバグを生む原因になります。
まとめ:道具を使い分けるのがプロの流儀
CSSには似たような機能を持つセレクタが溢れています。
- `^=` は「とりあえず全部拾いたい」とき
- `=` は「どこかに含まれていればOK」なとき
- そして `|=` は「意味のある境界として、ハイフン区切りを厳密に扱いたい」とき
この使い分けができるようになると、CSSのコードは驚くほど堅牢になり、後からやってくるメンバーが修正で頭を抱えることもなくなります。
「どのセレクタが一番最適か?」を常に自問自答し、プロジェクトの命名規則という土台を愛する。そんな泥臭いこだわりこそが、優れたフロントエンドエンジニアへの第一歩です。さあ、明日のコードからぜひ試してみてください。
タイトルとURLをコピーしました - `

コメント