【テクニカル・上級編】counter-resetとcounter-incrementによる連番制御 – HTML実践ガイド

DOM構造に縛られない連番制御：CSS Countersの深淵と、大規模設計における「脆さ」の克服

フロントエンドの設計において、HTMLのセマンティクスと表示上の連番（インデックス）を分離したいという欲求は、一度は直面する課題だ。`

そこで我々が武器にするのが、CSS Counters（`counter-reset`, `counter-increment`, `content: counter()`）だ。しかし、これを単なる「おまけ機能」として雑に扱うのは、大規模アプリケーションにおいては火種を撒く行為に等しい。本稿では、ブラウザのレンダリングパイプラインを意識した上での、堅牢かつスケーラブルな連番管理の設計論を紐解く。

CSS Countersの基本設計：レンダリング負荷を最小化する

CSS Countersの最大の利点は、JavaScriptによるDOMの書き換え（`innerHTML`の全置換など）を回避できることだ。DOMの変更は高コストな「リフロー」を引き起こすが、CSSレベルでの表示制御であれば、ブラウザは再描画のみ、あるいは合成のみで済むケースが多い。

/ カウンタの初期化とインクリメントの定義 /
.section-container {
/
counter-resetは現在のスコープでカウンタを初期化する。
名前空間の衝突を避けるため、コンポーネント単位で命名するのが鉄則。
/
counter-reset: custom-index 0;
}

.item {
/ incrementを各要素に適用する。ここでの負荷は微々たるものだ /
counter-increment: custom-index;
}

.item::before {
/ contentプロパティでカウンタ値を取得 /
content: counter(custom-index) “. “;
}

非同期データと「競合」という悪夢

SPA（Single Page Application）において最も厄介なのは、非同期でアイテムが追加・削除された際の連番の不整合だ。JavaScriptで配列のインデックスを直接HTMLに埋め込む設計は、削除や並び替えが発生した瞬間に負債と化す。

CSS Countersはブラウザのレンダリングエンジン側で計算されるため、DOMが正しく配置されさえすれば、連番の整合性はブラウザが保証してくれる。これが最大の恩恵だ。しかし、ここで注意すべきは「カウンタのスコープ」である。

スコープ分離によるバグ回避

コンポーネントがネストしている場合、親のカウンタを子が意図せず引き継いでしまうことがある。これを防ぐには、`counter-reset`を適切な階層で再定義し、コンテキストを隔離する。

/ コンポーネント境界でのカウンタ隔離 /
.component-root {
/ このコンポーネント内だけで完結するカウンタを定義 /
counter-reset: component-local-counter 0;
}

TypeScriptを用いた「型安全なカウンタ管理」の設計

CSS Countersを直接操作するのではなく、データモデル側で「カウンタをリセットすべきトリガー」を管理する設計を推奨する。TypeScriptを利用して、カウンタが必要なリスト要素の型定義を厳格化しよう。

interface ListElement {
id: string;
label: string;
// CSSのカウンタ制御を意識したフラグを持たせる設計
shouldResetCounter?: boolean;
}

Reactなどのフレームワークでレンダリングする際、
shouldResetCounterがtrueの要素にクラスを付与する戦略

/
const renderList = (items: ListElement[]) => (

{items.map((item) => (

{item.label}

))}

);

エッジケース：不可視要素とパフォーマンスの罠

技術者として忘れてはならないのは、`display: none;` や `visibility: hidden;` の挙動だ。

`display: none;` に設定された要素は、カウンタのインクリメント対象から除外される。これはフィルタリング機能を持つリストでは「都合の良い挙動」だが、逆に言えば、非表示の要素も数えたい場合にはCSS Countersは使えない。
パフォーマンス面では、カウンタの計算自体は非常に軽量だが、数万件の要素に対して複雑なCSSセレクタで `counter-increment` を適用すると、ブラウザのスタイル計算（Style Recalculation）のコストが増大する。

大規模なリスト（仮想スクロールを導入するレベル）では、CSS Countersに頼らず、仮想DOMのレンダリングロジック内でインデックスを計算する方がメモリ効率が良い場合もある。「CSSで解決できるか？」ではなく「CSSで解決すべきか？」を常に自問すること。

結論：技術は「仕組み」で制御せよ

CSS Countersは、HTMLの構造（DOM）と表示上の連番を切り離すための極めて強力なツールだ。しかし、それを活かすも殺すも設計次第である。

1. 命名空間を分離し、スコープを閉じること。
2. DOMのレンダリングロジックと連番の表示ロジックを分離すること。
3. フィルタリングや非同期更新が頻発する環境では、CSS Countersの制約（非表示要素はカウントされない）を仕様として組み込むこと。

公式マニュアルをなぞるだけでは得られない、この「泥臭い制御」こそが、堅牢なUIを作り上げるエンジニアの矜持である。次回の実装時には、ぜひこの「カウンタのスコープ」を意識した設計を試みてほしい。きっと、コードの美しさが一段階上のレベルへ昇華されるはずだ。