リストマーカーの再発明：`::marker` がもたらす描画レイヤーの最適化とアーキテクチャへの影響
フロントエンドの現場において、`
- ` や `
- リストマーカーのスタイルを型定義
{children}
- ` のスタイル調整に頭を抱えた経験は誰にでもあるはずだ。かつて我々は、`list-style-type` の限定的な表現力に絶望し、`li::before` に無理やり `content` を流し込み、`position: absolute` で位置を微調整するという「ハック」を繰り返してきた。
しかし、現代のブラウザエンジンには `::marker` という洗練された擬似要素が実装されている。これは単なる「見た目の変更」を超え、レンダリングパイプラインにおける効率化と、宣言的UIの保守性を劇的に向上させる可能性を秘めている。本稿では、この小さな機能が大規模アプリケーションの設計にどのような恩恵をもたらすのか、深掘りしていく。
なぜ `::marker` を選ぶのか：レンダリング負荷の観点
従来の `::before` によるマーカーの実装は、DOMノード（あるいは擬似要素）を通常のコンテンツフロー内に生成するため、ボックスモデルの計算において他の要素と干渉しやすい。一方、`::marker` はブラウザのレンダリングエンジンレベルで「リスト項目の一部」として最適化されている。
特に、リストアイテムが数千件に及ぶ動的なデータグリッドや長大なドキュメントにおいて、`::before` を多用するとリフロー計算のコストが積み重なる。`::marker` は、CSSのプロパティとして非常に限定的な範囲（`color`, `font-size`, `content` など）でしか操作できないという制約があるが、これは逆に言えば「ブラウザが描画コストを予測しやすい」ことを意味する。
実践：型安全を担保したスタイルコンポーネント設計
TypeScriptとCSS-in-JS（またはCSS Modules）で運用する場合、このマーカーの制御をコンポーネントのPropsとして露出させる必要がある。以下は、型安全を維持しつつ `::marker` を制御するための設計の一例だ。
/
/
type MarkerTheme = {
color: string;
content: string;
};
// CSS ModulesやTailwindで制御する場合も、
// CSS変数(Custom Properties)を経由するのがベストプラクティス
const ListItem: React.FC<{ theme: MarkerTheme; children: React.ReactNode }> = ({ theme, children }) => {
return (
);
};
/ CSS側での定義 /
.custom-list-item {
/ ::markerは継承関係が独特であることに注意 /
&::marker {
color: var(–marker-color);
content: var(–marker-content);
/ font-sizeも指定可能だが、親要素のline-heightとの競合に注意 /
}
}
エッジケースと「ハマりどころ」を回避する
`::marker` を導入する際、最も注意すべきは「ブラウザごとのデフォルト挙動の差異」と「アクセシビリティ（A11y）」だ。
1. イベントの透過性: `::marker` はマウスイベントを拾わない。マーカーをクリックして何かのアクションを起こしたいという要件があるなら、`::marker` ではなく、`display: flex` を利用した擬似要素（`::before`）による実装に戻るべきだ。
2. 計算済みプロパティの制約: `::marker` に適用できるプロパティは `animation` や `transition` を受け付けない。動的にマーカーをアニメーションさせたいという要望は、フロントエンドエンジニアが最も頭を抱えるポイントだが、現状では「マーカー自体を動かす」のではなく、「マーカーを非表示にして、`::before` で再実装する」というトレードオフを検討する必要がある。
3. スクリーンリーダーとの競合: `::marker` を `content: “”` で消去した場合、スクリーンリーダーがリストアイテムを「リスト」として認識できなくなる恐れがある。`list-style-type: none` を使用する場合と同様、セマンティクスを損なわないよう注意深くマークアップする必要がある。
結論：技術選定のシビアな視点
`::marker` は、シンプルでパフォーマンスに優れたUIを構築するための強力な武器だ。しかし、複雑なインタラクションが求められるアプリケーションにおいては、従来の `::before` 手法との住み分けを明確にしなければならない。
「静的なドキュメントや一覧表示には `::marker` を、複雑な状態を持つインタラクティブなリストにはカスタム擬似要素を」。
この使い分けができるかどうかが、プロダクトのコードベースを「技術的負債」から「資産」へと昇華させる境界線となる。ブラウザの仕様を盲信するのではなく、その裏側にあるレンダリングコストを常に意識する。それこそが、我々エンジニアが目指すべきプロフェッショナリズムの形ではないだろうか。
コメント