【テクニカル・上級編】list-style-imageとbackground-imageの比較 – HTML実践ガイド

リストマーカーの深淵：`list-style-image`を捨てて`background-image`に魂を込める理由

Web開発の現場において、リストマーカーのカスタマイズほど「実装者の美学」が問われる箇所はない。

新人エンジニアが `list-style-image: url(‘marker.png’);` を書いて満足する横で、シニアエンジニアは眉をひそめる。なぜか？それは、このプロパティがブラウザのレンダリングエンジンに対してあまりに「無責任」であり、現代の堅牢なUI実装において致命的な柔軟性の欠如を露呈するからだ。

今回は、なぜ我々がリストマーカーに `list-style-image` を使わず、`background-image` を駆使するのか。その技術的根拠と、大規模アプリケーションにおける最適解を深掘りする。

`list-style-image` の「罪」と妥協点

`list-style-image` は、CSS仕様上の「レガシーな遺物」に近い。このプロパティの最大の問題は、マーカーの配置制御がブラウザの実装に依存しすぎる点にある。

1. 配置の不自由さ: マーカーの垂直方向の微調整や、テキストとの距離感（パディング）をCSSで厳密にコントロールすることが極めて困難だ。
2. スケーラビリティの欠如: DPIが高いRetinaディスプレイ環境下で、このプロパティは「ボケる」か「制御不能になる」かの二択を迫る。`image-set` を使ったレスポンシブな画像切り替えも、このプロパティの文脈では非常に扱いづらい。
3. レンダリングのブラックボックス: ブラウザごとにマーカーのレンダリングタイミングが異なり、特に大規模な動的リストにおいて、描画の瞬間にマーカーが一瞬遅れて表示される「チラつき」の原因となる。

戦略的解法：`background-image` によるマーカーの再定義

我々が採用すべきは、`li` 要素の `::before` 疑似要素を活用し、`background-image`（あるいは `mask-image`）でマーカーを描画する手法だ。これには明確なアーキテクチャ上のメリットがある。

パフォーマンスとレンダリングの最適化

`background-image` を使用することで、以下の制御が可能になる。

リフロー・リペイントの最小化: 疑似要素として分離することで、リストのコンテンツが更新されても、マーカー部分の描画コストを独立して管理できる。
ベクターの活用: `mask-image` を用いれば、単一のSVGソースで色変更やサイズ変更が自由自在になる。これはアイコンフォントのような「文字化け」や「レンダリングの癖」のリスクを回避できる最強の選択肢だ。

実装例：型安全とコンポーネント指向

TypeScriptでUIコンポーネントを設計する場合、以下のようにマーカーのバリエーションを型で厳格に縛るのが正解だ。

// マーカーの種類を型で定義し、保守性を確保する
type MarkerVariant = ‘check’ | ‘arrow’ | ‘dot’;

interface ListItemProps {
variant: MarkerVariant;
children: React.ReactNode;
}

// CSS Module想定の記述
const ListItem: React.FC = ({ variant, children }) => {
return (

{children}

);
};

/
CSS側での制御：
list-style-type: none でデフォルトを消去し、
::before で背景として配置する。
/
.list-item {
list-style-type: none;
padding-left: 1.5rem;
position: relative;
}

.list-item::before {
content: ”;
position: absolute;
left: 0;
top: 0.25rem; / テキストとの垂直位置をピクセル単位で制御可能 /
width: 1rem;
height: 1rem;
/ mask-image を使うことで、CSSで色を制御可能にする /
background-color: currentColor;
mask-image: var(–marker-icon);
mask-repeat: no-repeat;
}

エッジケースと非同期の競合への対策

大規模アプリケーションでは、画像リソースの非同期読み込みが「レイアウトシフト」を誘発する。`list-style-image` はこの点において全く無力だが、`background-image` は `aspect-ratio` や `contain-intrinsic-size` と組み合わせることで、描画前の領域確保が可能だ。

特に、画像が外部CDNから読み込まれる場合、`content-visibility: auto` や `will-change: transform` を適切に適用し、リストのスクロールパフォーマンスを担保してほしい。

結論：なぜ「泥臭い」方を選ぶのか

`list-style-image` は、簡単なドキュメントサイトなら良い。しかし、我々が扱うのは複雑な状態管理を持つWebアプリケーションだ。

「CSSのプロパティを一つ選ぶ」という小さな意思決定が、数ヶ月後の「謎のレンダリングバグ」を未然に防ぐ。`background-image` をベースにしたマーカー実装は、一見するとコード量が増えるように見えるが、それは将来の技術的負債を払い前払いしているだけなのだ。

技術とは、公式マニュアルをなぞることではない。ブラウザという名のエンジンの挙動を理解し、その上で最も堅牢で、かつ美しいアーキテクチャを構築することにこそ、エンジニアの醍醐味があるのではないだろうか。