CSSカウンターという「最後の楽園」：DOMを汚さず、ロジックを制御するアーキテクチャ設計
フロントエンドの世界では、マークアップとスタイルの境界線は常に曖昧になりがちです。特に「リストの番号付け」という極めて単純なUI要件に対し、私たちはついJSで`map()`を回し、ReactのStateに依存したインデックスをDOMに書き出し、その結果として不要な再レンダリングやレイアウトシフトを招いてしまう。そんな「JS依存の罠」に陥っていないでしょうか。
今回は、あえて`ol`タグという制約から離れ、`counter-reset`と`counter-increment`というCSSの隠れた強力なプリミティブを用いて、パフォーマンスと保守性を両立する「CSS駆動のナンバリング」について深掘りします。
なぜ今、CSSカウンターなのか：レンダリング負荷の観点から
モダンブラウザのレンダリングパイプラインにおいて、JSによるDOM操作はコストが高い処理です。特に大規模なリストで数値が頻繁に更新される場合、DOMのテキストノードを書き換えることは、ブラウザに再レイアウト（リフロー）を強いる引き金になります。
一方、CSSカウンターはブラウザのレンダリングエンジン内で完結します。「表示のための数値」をJSで管理する必要がないということは、メモリリークのリスクを減らし、メインスレッドの占有時間を最小化することを意味します。これは、複雑なUIを扱うテックリードにとって無視できないメリットです。
実装の勘所：セマンティクスを破壊しないための設計
CSSカウンターを導入する際、最も注意すべきはアクセシビリティです。`::before`疑似要素に数値を突っ込む手法は強力ですが、スクリーンリーダーがこれをどう解釈するかを常に意識しなければなりません。
/ カウンターの初期化。スコープを限定することで予期せぬ衝突を防ぐ /
.list-container {
counter-reset: custom-index 0;
}
.list-item {
/ カウンターの加算。擬似要素を使うことでDOMを汚さない /
counter-increment: custom-index;
display: flex;
align-items: center;
}
.list-item::before {
/ CSS変数と組み合わせて、動的なスタイル調整も可能 /
content: counter(custom-index) “. “;
font-weight: bold;
margin-right: 0.5rem;
/ 視覚的装飾とアクセシビリティの分離を意識する /
}
TypeScriptとCSSの境界：型安全なインジェクション
CSSカウンターの弱点は「JSから値を直接参照できないこと」です。しかし、上級エンジニアであれば、CSS変数（Custom Properties）をハブにしてJSと通信させるアーキテクチャを選択します。
// 型定義でCSS変数を管理し、予期せぬ値を排除する
type CounterConfig = {
startValue: number;
prefix?: string;
};
const applyCounterConfig = (element: HTMLElement, config: CounterConfig) => {
// styleオブジェクトへの直接代入はパフォーマンスを最適化する
element.style.setProperty(‘–counter-start’, config.startValue.toString());
};
CSS側では `counter-reset: custom-index var(–counter-start, 0);` とすることで、JSからの設定入力を受け入れつつ、CSS単体でのデフォルト挙動も維持する堅牢な構造が作れます。
エッジケースにおける「重大なバグ」を回避する
CSSカウンター運用で最も恐ろしいのは、「DOMの削除による番号の飛び」と「非同期読み込みによる順序の不整合」です。
1. DOMの削除と再構築: 仮想DOMライブラリ（React等）を使用する場合、コンポーネントのアンマウントと再マウントによってカウンターがリセットされる場合があります。これを防ぐには、`counter-reset`を親コンテナではなく、さらに上位のスコープで管理するか、`contain: layout;` を指定してレイアウトの境界を明示的に作成し、ブラウザの再計算コストを局所化するのが定石です。
2. 非同期データの競合: 非同期でリストアイテムが追加される際、DOMの生成タイミングとカウンターの加算タイミングがズレることがあります。これには`MutationObserver`でDOMの挿入を監視し、カウンターを再評価させるトリガーを仕込むのが、最も泥臭く、かつ確実な防御策です。
結論：技術は「最適解」の選択である
CSSカウンターは、単なる「見た目の調整ツール」ではありません。それは、「DOMに含めるべきデータ」と「スタイルとして描画すべきデータ」を峻別する、エンジニアの設計哲学そのものです。
安易にすべてのロジックをJSに寄せず、ブラウザのネイティブ機能を最大限に活用する。この「引き算のアーキテクチャ」こそが、複雑化するWebアプリケーションにおいて、フロントエンドエンジニアが生き残るための鍵となるでしょう。
次にリストを実装する際、その`ol`タグをマークアップする前に一呼吸置いてみてください。その番号、本当にJSで管理する必要がありますか？ もしかしたら、CSSカウンターこそがそのコードベースをより軽く、より速くする唯一の正解かもしれません。
コメント