タグアーカイブ CSSレイアウト

CSS最新情報まとめ。Safariテスト手法、::checkmark、データ属性によるアンカー制御

CSS最新情報まとめ。Safariテスト手法、::checkmark、データ属性によるアンカー制御

Web制作の現場では、新しいCSS機能のキャッチアップとブラウザ間の動作検証が日々の課題だ。CSS-Tricksの定期連載「What’s !important」第12回では、5月末時点で注目すべき6つのトピックが取り上げられている。

実機がないSafariでのテスト手法から、スタイル付与が難しかったチェックマークを操作できる新疑似要素、さらには一度は策定が見送られたHTML属性に代わるデータ属性を用いたアンカー制御テクニックまで、幅広い知見が共有された。

本記事ではこれらのトピックを整理し、実務への応用ポイントを解説する。とくにCSS-Tricksの著者Geoff Graham氏が自ら考案したアンカー制御の代替手法は、現場の制約を乗り越えるヒントになるはずだ。

Safariがない環境でSafariテストを実施する手法

Safariがない環境でSafariテストを実施する手法

Webブラウザのシェアで2番手に位置するSafariだが、その利用はAppleデバイスに限定されている。macOSやiOSを持たない開発者にとって、Safari専用のバグ潰しやレイアウト確認は長年の悩みの種だった。

Frontend Mastersの記事でDeclan Chidlow氏が解説したのは、予算や環境に制約がある状況下での実践的なSafariテスト手法だ。物理デバイスを持たずに検証するアプローチは、大きく3つのカテゴリに分けられる。

クラウド型テストサービス
BrowserStack、LambdaTest 等のサービスを使い、クラウド上の実機Safariで検証する。クロスブラウザテストの定番手法であり、全機能が動作する。
Playwright / WebKit ビルドの活用
PlaywrightのWebKitビルドをLinuxで動かせば、Safariのレンダリングエンジンをローカル検証できる。UIの挙動や自動テストに適している。
Epiphany(GNOME Web)ブラウザ
Linuxで動作するEpiphanyブラウザはWebKitエンジンを採用している。Safariと完全に同一ではないものの、簡易的な互換性チェックに使える。
クラウド型  ローカル自動化  WebKit系ブラウザ

どの手法を選ぶべきか

最も確実なのはクラウド型のテストサービスだが、無料枠には限りがあり、動作速度もローカル環境に劣る。一方PlaywrightのWebKitビルドは、Safariのレンダリングエンジンを手軽に再現できる点で優れている。ただしフォントレンダリングや一部のOS依存機能まではカバーしきれない。

重要なのは「どのレベルで検証が必要か」の線引きだ。レイアウトの崩れやCSSプロパティの対応状況を確認するだけならPlaywrightで十分だが、タッチ操作やスクロール挙動、Apple Pay連携などの最終検証は、必ず実機かクラウドサービスで行うべきである。

::checkmark疑似要素が解決するチェックマークのスタイル課題

::checkmark疑似要素が解決するチェックマークのスタイル課題

チェックボックスやラジオボタン、セレクトボックスのチェック状態を示すマーク。このUIパーツは長年、開発者の手によって擬似的に再現されてきた。本来のチェックマーク(チェック状態を示すインジケーター)にはCSSで直接スタイルを当てられなかったからだ。

Sunkanmi Fafowora氏がPiccalilliで紹介した::checkmark疑似要素は、この制約を根本から解決する。チェックボックスだけでなく、ラジオボタンやセレクトボックスのチェック状態にも作用する点がポイントだ。

従来の手法(Before)
チェックボックス本体を非表示にし、label要素に背景画像やCSSシェイプで擬似チェックマークを描画する。コード量が多く、アクセシビリティ上の注意点も多い。
::checkmark 疑似要素(After)
ブラウザ標準のチェックマークに対して、::checkmark で色・サイズ・形状を直接スタイリングできる。セマンティックなHTMLを維持したまま見た目をカスタマイズ可能。

この機能がブラウザに実装されれば、チェックボックス周りのCSSトリックは大幅に削減されるだろう。とくにフォームのブランディング要件が厳しいプロジェクトでは、作業工数の縮小に直結する。

border-shapeとshape()で広がるシェイプ表現の選択肢

border-shapeとshape()で広がるシェイプ表現の選択肢

CSSで複雑な図形を描くとき、これまではclip-pathが主戦場だった。Temani Afif氏がCSS Tipで示したのは、border-shapeプロパティとshape()関数を組み合わせるアプローチだ。

clip-pathが要素全体を切り抜くのに対し、border-shapeは境界線に沿ってシェイプを適用する。この違いにより、輪郭のみのシェイプや、塗りつぶしと輪郭を組み合わせた表現が容易になる。

clip-path のみの表現
要素を指定したシェイプで切り抜く。切り抜かれた部分は非表示になり、背景も透過する。輪郭だけを残す表現には追加の工夫が必要。
border-shape + shape()
境界線に沿ったシェイプ変形が可能。塗りつぶし・輪郭のみ・切り抜きの3パターンを同じシェイプ定義から切り替えられる。
Afif氏のデモでは、波型シェイプをアウトライン版・塗りつぶし版・切り抜き版の3種で提示している。

実務での活用シーンとしては、カードUIの装飾枠や、セクション区切りに使うカスタムシェイプが考えられる。とくにECサイトの商品カードやブランドページのビジュアルセクションでは、微妙な形状の差別化がUIの印象を大きく左右する。

sibling-index()とsibling-count()がもたらす数理レイアウト

sibling-index()とsibling-count()がもたらす数理レイアウト

兄弟要素の中で「自分が何番目か」「兄弟全体で何個あるか」をCSSだけで取得できるsibling-index()sibling-count()。この2つの関数はBaseline(ブラウザ間の相互運用が確立された機能群)への移行が目前に迫っている。

Smashing MagazineでDurgesh Pawar氏が公開した詳細な解説では、これらの関数を使った数学的レイアウトの実例が数多く紹介されている。たとえば、兄弟要素の数に応じてグリッドの列数を動的に変えたり、要素の位置に比例したスタイルを適用したりといったパターンだ。

STEP 1 CSSが兄弟関係をカウント
STEP 2 総数や位置に応じて計算式を適用
STEP 3 レイアウトや色・サイズが動的に変化
従来はJavaScriptで要素数を取得しCSS変数に渡す必要があったが、CSS単独で完結する。

とくにCMSで生成されるリストや、ユーザー投稿型のコンテンツ一覧では、アイテム数が動的に変動する。このようなシーンで、JavaScriptに頼らずCSSだけでレイアウトを最適化できる価値は大きい。Pawar氏の記事ではView Transitionsに関する連載もCSS-Tricksで展開されており、合わせて参照することを勧める。

anchor属性の代案としてのデータ属性制御テクニック

anchor属性の代案としてのデータ属性制御テクニック

これはCSS-Tricksの著者Geoff Graham氏自身の取り組みだ。CSSアンカー位置指定において、HTML属性anchorの策定が見送られたことを受け、同氏はデータ属性とattr()関数を用いた代替手法を考案した。

アンカー位置指定とは、ある要素(ターゲット)を別の要素(アンカー)からの相対位置で配置する仕組みである。ポップオーバーやツールチップの位置決めに使われる。本来anchor属性は、このターゲットとアンカーの紐付けをHTML上で宣言的に行うために提案されていた。

見送られた anchor 属性(Before)
<div anchor="anchorA">Boat A</div> <div id="anchorA">Anchor A</div>
シンプルで直感的だが、策定プロセスでドロップされた。
Graham氏のデータ属性手法(After)
<div data-boat="anchorA">Boat A</div> <div data-anchor="anchorA">Anchor A</div>
カスタム識別子を使う場合と、attr()で直接値を取得する場合の2パターンを提示。

この手法の実用性は、CSSのattr()関数の進化に依存している。attr()<custom-ident>型をサポートするようになれば、データ属性の値をCSS内で参照し、アンカー名として利用できるようになる。ブラウザ実装の進捗を注視しつつ、先行してHTML構造をデータ属性ベースに整えておくことは、将来の移行コストを下げる有効な準備だ。

State of CSS 2026に見る開発者の学習負荷と向き合い方

State of CSS 2026に見る開発者の学習負荷と向き合い方

毎年恒例のState of CSS調査が2026年版の回答受付を開始した。今回の特徴は、冒頭文から明確に打ち出された「取捨選択」の姿勢である。調査の主催者は、CSSの進化があまりに速く、すべてを追いかけることが逆に開発者の負担になっている現状を率直に認めている。

従来の課題
新機能が次々と登場し、キャッチアップすべきリストが際限なく増える。知識の陳腐化への不安が常につきまとう。
2026年版の方向性
調査対象の機能を厳選し、本当に重要なものだけに絞り込む。学習の優先順位付けを支援する。

CSS-TricksのGraham氏もこの方針に賛同しつつ、「CSSの新機能を学んでいるときにさらに別の機能がリリースされる感覚は、圧倒的でありながら最高の体験でもある」とコメントしている。業務で必要な機能を見極め、それ以外は「面白そうだから」という理由で触れる余裕も持ちたいところだ。

ちなみに今回の調査期間中、Firefox 151がリリースされ、コンテナスタイルクエリがBaselineに到達した。デスクトップ向けではSafariの未対応が残るものの、モバイル含め多くの環境で動作する段階に入っている。またDocument Picture-in-Picture APIも新たに追加され、Webプラットフォーム全体の進化は依然として加速中だ。

この記事のポイント

  • Safariのテストにはクラウドサービス・Playwright WebKitビルド・Epiphanyブラウザの3段階がある
  • ::checkmark疑似要素は、チェックボックス・ラジオ・セレクトのチェック状態を直接スタイリングできる
  • border-shapeshape()の組み合わせで、輪郭・塗りつぶし・切り抜きを同一シェイプから切り替え可能
  • sibling-index()sibling-count()により、CSSだけで兄弟要素の位置と総数を取得できる
  • 見送られたanchor属性の代わりに、データ属性とattr()を組み合わせたアンカー制御が提案されている
CSSのsibling-index()とsibling-count()でDOMを数式レイアウト

CSSのsibling-index()とsibling-count()でDOMを数式レイアウト

CSSに<sibling-index()>と<sibling-count()>という2つの関数が追加された。これらは要素の兄弟関係を「数値」として取得し、calc()の中で計算できる。2025年6月時点でChrome 138とSafari 26.2が対応済みで、Firefoxも実装が進行中だ。

この新機能の最大の価値は「ブラウザがすでに知っている情報を、CSSから直接引き出せる」点にある。従来はJavaScriptでループ処理するか、Sassで大量の:nth-child()ルールを生成するしかなかった。それが1行のCSSで完結する。

本記事では、sibling-index()とsibling-count()の基本から実践パターン、注意点までを解説する。WordPressサイトのカスタムCSSを書く制作者にも役立つ内容だ。

従来のスタガードアニメーションが抱えていた問題

従来のスタガードアニメーションが抱えていた問題

カードグリッドに1枚ずつ遅延させて表示する「スタガードカスケード効果」は、見た目がよく実装も簡単に思える。ところが実際には、かなり面倒なコードが必要だった。

:nth-child()の限界

10枚のカードに異なるアニメーション遅延を設定したいとする。従来の方法では、こう書くしかなかった。

li:nth-child(1) { --idx: 1; }
li:nth-child(2) { --idx: 2; }
li:nth-child(3) { --idx: 3; }
/* ...8個分続く... */
li:nth-child(10) { --idx: 10; }

li {
  animation-delay: calc(var(--idx) * 100ms);
}

10項目なら10ルールで済むが、50項目なら50ルールだ。Sassのループでビルド時に数百個のセレクタを生成する方法もあるが、CSSファイルが膨れ上がる。Roman Komarov氏が考案したO(√N)戦略でも、1023要素をカバーするのに63ルールが必要になる。

JavaScript依存の落とし穴

もう1つの方法は、JavaScriptでDOMを走査してインラインスタイルを書き込む方式だ。style="--index: 3" を各要素に付与する。動作はするが、レイアウトのための値がスクリプトに分散し、半年後に別の開発者がコンポーネントをリファクタリングした際に静かに壊れる。ブラウザはすでに「どの要素が3番目の子か」を知っているのに、CSSからはその情報にアクセスできなかった。

Smashing Magazineの記事で著者の一人が指摘するように、この状況は「ブラウザがすでに持っているデータを、わざわざ手動で再計算している」矛盾だった。

sibling-index()とsibling-count()の基本

sibling-index()とsibling-count()の基本

この2つの関数はCSS Values and Units Module Level 5で定義されている。どちらも引数を取らず、CSSの宣言内で直接数値として使える点が革新的だ。

sibling-index()
親要素の子要素の中で、その要素が何番目かを整数で返す(1ベース)
1番目 1
5番目 5
50番目 50
テキストノードやコメントはカウントしない。要素ノードのみを数える。
sibling-count()
親要素が持つ子要素の総数を整数で返す
JavaScriptの element.parentElement.children.length に相当
親要素が変われば値も変わる。スタイルシート内で動的に評価される。
両関数とも calc() min() max() round() mod() で計算可能

counter()との違いに注意したい。counter()は文字列を返し、疑似要素のcontentプロパティ内でしか使えない。一方、sibling-index()はCSS内の任意の場所で使える実数だ。時間値や角度、ピクセル値との計算もCSSが自動的に型変換する。

:nth-child()との本質的な違い

:nth-child()は「セレクタ」であり、要素を選択するための仕組みだ。calc(:nth-child() * 10px)のような書き方はできない。sibling-index()は「宣言の中で使える値」を生成する。両者は役割が異なり、補完関係にある。

実践的なユースケース

実践的なユースケース

これらの関数が整数を返すと理解できれば、応用の幅は一気に広がる。以下に、WordPressサイトのカスタマイズにも活用できるパターンを紹介する。

リバーススタガー

最後の項目から先にアニメーションさせたい場合は、引き算で反転する。

.card {
  animation: fade-in 0.4s ease both;
  animation-delay: calc((sibling-count() - sibling-index()) * 80ms);
}

最後の子要素は (N – N) × 80ms = 0ms で即座に表示される。最初の子要素は (N – 1) × 80ms の遅延となる。ページ読み込み直後からアニメーションが始まり、待ち時間が生じない。

自動均等幅

タブやカラムの幅を子要素の数に応じて自動調整する。

.tab {
  width: calc(100% / sibling-count());
}
従来の固定幅(Before)
タブ1
タブ2
タブ3
※固定幅で3つまでは収まるが、増えるとはみ出す
sibling-count() で自動均等割り(After)
タブ1
タブ2
タブ3
タブ4
タブ5
※5個でも自動で20%ずつ均等割り。項目の増減にCSSだけで追従
※このデモはsibling-count()の概念を視覚化したイメージです。実際の動作はChrome DevToolsで確認してください。

5つのタブなら各20%、6つ目が追加されれば約16.66%になる。メディアクエリやリサイズ監視、JavaScriptは不要だ。ただし項目が増えすぎてタブが細くなりすぎる場合は、Flexboxの折り返しなど別の手法を併用する判断も必要になる。

色相分布

カラーホイール上で均等に色を分散させる。

.swatch {
  background-color: hsl(
    calc((360deg / sibling-count()) * sibling-index()) 70% 50%
  );
}

3項目なら120度間隔、12項目なら30度刻みで色相が割り当てられる。DOM内の項目数に応じてパレットが自動調整されるため、JavaScriptのカラーライブラリで行っていた処理をCSSだけで完結できる。

円形メニュー

項目を円周上に配置する計算も、CSSの三角関数と組み合わせればシンプルになる。

.radial-item {
  --angle: calc((360deg / sibling-count()) * sibling-index());
  --radius: 120px;

  position: absolute;
  left: calc(50% + var(--radius) * cos(var(--angle)));
  top: calc(50% + var(--radius) * sin(var(--angle)));
  transform: rotate(calc(var(--angle) * -1));
}

6項目なら六角形、8項目なら八角形になる。項目を追加・削除すればレイアウトが再計算される。JavaScriptで座標を逐一計算する必要はない。

Z-indexスタッキング

カードを扇状に重ねる表現も1行で済む。

.card {
  z-index: calc(sibling-count() - sibling-index());
}

最初のカードが最も高いz-indexを持ち、最後のカードは0になる。逆順にしたい場合は計算式を反転すればよい。

注意点と制限事項

注意点と制限事項

仕様を読み込んでも気づきにくい落とし穴がいくつかある。実際に使い始める前に把握しておきたい。

Shadow DOMのスコープ

sibling-index()とsibling-count()は「DOMツリー」に対して動作し、フラット化された視覚ツリーではない。この違いはWeb Componentsを使う場面で問題になる。

カスタム要素内のシャドウDOMで内部のdivにsibling-index()を適用すると、slotで投影された外部コンテンツはカウントされない。slotが300要素を投影していても、シャドウツリー内ではsection直下の子要素はslot要素とdivの2つだけだ。

また、外部のスタイルシートから::part()経由でコンポーネント内部にsibling-index()を使おうとすると、ブラウザは0を返す。これはサードパーティコンポーネントの内部構造を外部CSSから探られるのを防ぐための意図的な設計だ。

疑似要素はカウントされない

::beforeや::afterは兄弟要素ではない。sibling-count()に含まれず、自身のsibling-index()も持たない。ただし、疑似要素の宣言内でこれらの関数を使うことは可能だ。その場合、疑似要素ではなく「元の要素」のインデックスが評価される。

display:noneでもカウントされる

これは特に注意が必要だ。display:noneを指定した要素はレイアウトツリーから消えるが、DOMツリーには残っている。sibling-index()はDOMツリーを見るため、非表示要素もカウントしてしまう。

⚠ 問題が起こるケース
1番目:リンゴ(表示)
2番目:バナナ(display:noneで非表示)
3番目:チェリー(表示)← 3番目のまま
※チェリーは視覚的には2番目だが、sibling-index()は3を返す
✓ 対策
検索フィルタなどで連続したインデックスが必要な場合は、非表示にするのではなくDOMから実際にノードを削除する

visibility:hiddenやopacity:0も同様にカウントされるが、これらは要素が空間を占有し続けるため直感的にも理解しやすい。display:noneだけが「視覚的に消えているのにDOMスロットを占有している」という特殊な挙動になる。

カスタムプロパティの即時評価

親要素で –idx: sibling-index() と定義すると、その値は親要素自身のインデックスで即座に解決される。すべての子要素が同じ固定値を継承してしまい、意図した動作にならない。

正しい方法は、関数を必要な要素自身に直接適用することだ。

/* 誤り:親で定義すると全子要素が同じ値を継承 */
.parent {
  --idx: sibling-index();
}

/* 正解:各子要素で個別に定義 */
.child {
  --idx: sibling-index();
  animation-delay: calc(var(--idx) * 100ms);
}

CSSWGでは@propertyのinherits:declaration拡張が議論されているが、まだ仕様化には至っていない。当面は各要素に直接適用するのが安全だ。

大規模DOMでのパフォーマンス

DOMの変更(要素の追加、削除、並べ替え)は、影響を受ける兄弟要素すべてのスタイル再計算を引き起こす。この処理はカスケードフェーズで行われるため、JavaScriptでループしてインラインスタイルを書き込む従来の方法よりは高速だ。

ただし、1万子要素を持つコンテナの先頭に要素を挿入すると、後続の全要素のインデックスが再計算される。ナビゲーションやカードグリッドのような通常の用途では問題にならないが、リアルタイム株価表示や無限スクロールフィードなど、数千ノードが常時入れ替わる場面では、仮想化ウィンドウ内でJavaScript管理のインデックスを使い続ける方が無難だ。

アクセシビリティへの配慮

これらの関数は純粋に「視覚的」なものである点を強調しておきたい。見た目を変えるだけで、意味を変えるわけではない。

sibling-index()の計算結果を使ってorderプロパティやグリッド配置でリストを視覚的に並べ替えた場合でも、スクリーンリーダーはDOMのソース順で読み上げる。キーボードのタブ順もDOM順に従う。視覚レイアウトとセマンティック構造が矛盾すれば、アクセシビリティ上の問題になる。

データグリッドやラジアルメニューなど、ツリーカウントに依存するインタラクティブなコンポーネントでは、JavaScriptでARIA属性(aria-posinsetやaria-setsize)を同期させる必要がある。CSSが計算した値とARIAが伝える情報が食い違えば、支援技術のユーザーには壊れた体験が提供される。

ブラウザ対応とフォールバック戦略

ブラウザ対応とフォールバック戦略

2025年6月時点で、Chrome/Edge 138とSafari 26.2が安定版で対応している。FirefoxはMozillaのポジションが肯定的で実装作業が進行中だが、安定版にはまだ含まれていない。最新の対応状況はcaniuseで確認することを推奨する。

ChromeとSafariで世界のトラフィックの約75〜80%をカバーするが、Firefox未対応の間はフォールバックが必須だ。

/* すべてのブラウザで動作するベースライン */
.item {
  width: 25%;
  animation-delay: 0ms;
}

/* 対応ブラウザでプログレッシブエンハンスメント */
@supports (z-index: sibling-index()) {
  .item {
    width: calc(100% / sibling-count());
    animation-delay: calc(sibling-index() * 80ms);
  }
}

Firefoxには静的なフォールバック、対応ブラウザには数式レイアウトを提供する。どのブラウザでもページが壊れることはない。

ポリフィルについて補足すると、JavaScriptで兄弟要素をループしてインラインスタイルを設定する方式は、まさにこれらの関数が置き換えようとしているものだ。Juan Diego Rodríguez氏が公開している段階的移行の手法では、Roman Komarov氏のカウンティングハックなど既存のCSSテクニックを橋渡しとして活用し、ネイティブ対応までの移行期間をしのぐアプローチを提案している。

今後の展望

今後の展望

現在の仕様では「すべての要素兄弟」をカウントするのみだが、CSSWGのIssue #9572では、:nth-child()と同様の「of セレクタ」引数の拡張が計画されている。

sibling-index(of .active)のような記法が実現すれば、特定のセレクタに一致する兄弟だけをカウントできる。全体で8番目の子だが.activeクラスを持つ中では3番目、という要素は3を返す。フィルタリングやトグル表示を伴う動的なUIでも、DOM操作なしで連続したインデックスを維持できるようになる。

さらに、children-count()とdescendant-count()の提案もCSSWGで議論されている。children-count()は要素が持つ子要素の数、descendant-count()はすべての子孫を再帰的にカウントする。sibling-index()とsibling-count()が「兄弟の間での自分の位置」という水平方向の情報を提供するのに対し、children-count()とdescendant-count()は「自分の下に何があるか」という垂直方向の情報を提供する。両方が揃えば、CSSからDOMツリーを俯瞰できるようになる。

10個の:nth-child()ルールを書きながら「もっと良い方法があるはずだ」と感じていた制作者にとって、その「もっと良い方法」がようやくブラウザに実装されつつある。CSSがDOMツリーを「理解」し始めたことで、レイアウトの表現力は次の段階に入ったと言える。

この記事のポイント

  • sibling-index()とsibling-count()はDOMツリーの構造をCSSから数値として取得できる新関数である
  • スタガードアニメーションや均等幅レイアウトが1行のCSSで完結し、JavaScriptや大量の:nth-child()ルールが不要になる
  • Chrome 138とSafari 26.2が対応済み、Firefoxは実装進行中で@supportsを使ったフォールバックが必須
  • display:noneの要素もカウントされる点、カスタムプロパティの即時評価、Shadow DOMのスコープに注意が必要
  • 視覚的な並べ替えはアクセシビリティ上の問題を引き起こすため、ARIA属性との同期が欠かせない