はじめに：2026年半ばのWebプラットフォーム動向
CSSの進化はここ数年で明らかに加速しています。Firefox 153、Chrome 151といったリリースが続き、Baselineに新規採用される機能が増える一方で、Safari・Firefoxが追随できていない機能もはっきりと分かれてきました。
本記事では、直近のWebプラットフォームアップデートの中から実務で即使える4つのトピックに絞って解説します。各項目で「Baseline状況」と「実務導入時の注意点」を併記していますので、社内のCSS設計やデザインシステム議論の参考になれば幸いです。
本記事はCSS-Tricksの What's !important #16（根拠資料）をベースに、日本のフロントエンド実務の観点から再構成したものです。
1. sibling-index() — アニメーション設計を変える関数
これまで nth-child() でインデックスを一つずつ計算していた時代が終わりつつあります。sibling-index() は兄弟要素の中での自身の位置を数値で返す関数で、animation-delay や transition-duration にそのまま渡せます。
/* カードリストを順次表示するstaggerアニメーション */
.card {
opacity: 0;
animation: fadeIn 0.4s ease forwards;
/* 各カードが自身の順番に応じて遅延 */
animation-delay: calc(sibling-index() * 80ms);
}
@keyframes fadeIn {
to { opacity: 1; transform: translateY(0); }
}
従来は :nth-child(1) { animation-delay: 0ms }、:nth-child(2) { animation-delay: 80ms } …と10個・20個を手書きするか、SCSSの @for ループを回す必要がありました。これが1行で済みます。
Baseline状況： Firefox 154にて2026年8月18日に正式サポート予定 → Baseline: Newly Available。Chrome・Safariは既にサポート済みで、Firefoxの追随待ちという状況です。
実務Tips
sibling-index()は1始まりです。0始まりに慣れている方はcalc((sibling-index() - 1) * 80ms)のように補正してください。- 純粋なCSS計算のため、SSR時のハイドレーション問題は発生しません。
- ただしDOM順序が変わればアニメーション順序も変わります。ソート機能付きリストでは意図した順序か必ず確認しましょう。
2. infinityキーワードとcontainer stuckクエリ
infinity："無限"を数値として扱う時代へ
calc() 内で infinity（および -infinity）を数値のように扱えるようになりました。実務で最も効果を実感しやすいのは corner-shape です。
/* 角丸を完全に角ばらせる */
.box-square {
corner-shape: superellipse(infinity);
/* corner-shape: square; と等価 */
}
/* ノッチ（凹み）形状に */
.box-notch {
corner-shape: superellipse(-infinity);
/* corner-shape: notch; と等価 */
}
「border-radius: 0 で十分では」と思われるかもしれませんが、border-radius が曲率そのものを除去するのに対し、superellipse(infinity) は丸いが視認できない状態を作るという違いがあります。アニメーションの中間状態を滑らかにつなぐ際に有用です。
container scroll-state(stuck:) — sticky検知の正道
position: sticky が実際に「張り付いた（stuck）状態か」をCSSのみで検知できる機能です。
.sticky-header {
position: sticky;
top: 0;
}
/* 親コンテナ内でヘッダーがstuck状態のときのみスタイル変更 */
@container scroll-state(stuck: top) {
.sticky-header {
box-shadow: 0 2px 8px rgba(0,0,0,0.15);
background: var(--bg-elevated);
}
}
これまで IntersectionObserver + センチネル要素で実装していた処理をCSS1行で置き換えられます。ただし2026年半ば時点でSafari・Firefoxは未サポートです。本番導入時は @supports で囲み、JSフォールバックを維持してください。
lazy loadingはデフォルトになるべきか
Lea Verou氏が提起した論点は**「loading="lazy" がデフォルトであるべきではないか」**というものです。現状は img・iframe に毎回明示する必要がありますが、CAS（Cascade Attribute Sheet）のような提案が実現すれば img, video { loading: lazy; } でグローバルデフォルトを変更し、例外のみ loading="eager" で上書きする設計が可能になります。
実務的には依然としてLCP画像には eager + fetchpriority="high" の組み合わせが定石です。無条件にlazyにすると、上部ヒーロー画像の表示が遅れ、Core Web Vitalsが逆走するケースが多発します。この点はVercel CLIでリアルタイムWeb Vitalsを確認する方法と合わせて読むと理解が深まります。
3. 日本のフロントエンド開発における適用文脈
日本企業の受託開発やエンタープライズ案件では、ブラウザサポートマトリクスがそのままスケジュールになります。sibling-index() や scroll-state(stuck:) を導入する際は、以下の順で判断することを推奨します。
- Baseline新規採用の有無を確認 → 未採用なら
@supports+ JSフォールバック必須 - ターゲットに旧ブラウザ（社内レガシーEdge等）が含まれるか確認
- デザインシステムに類似コンポーネントが既に存在するか確認 → 新CSS機能導入より既存拡張が保守性で優位
特に官公庁・金融系のようにクロスブラウザQAが長期化する案件では、新機能を「実験的ユーティリティクラス」として隔離し、Baseline移行時点で正式採用する戦略が安全です。
4. これらの技術の限界と注意点
- sibling-index()：DOM順序依存。仮想スクロール環境ではインデックスと視覚順序がずれる可能性あり。
- infinity：
corner-shapeはまだ実験段階。本番導入は名前通り「無限」を待つ必要があるかもしれません。 - container scroll-state(stuck:)：Safari・Firefox未サポート。
@supportsフォールバックなしで使うとiOSユーザーでレイアウト崩れが発生し得ます。 - lazy loadingデフォルト化議論：標準化議論の段階であり、ブラウザデフォルトが変更されると既存サイトのLCP測定値が変動する可能性があります。
5. 次の学習ステップ
- Baselineダッシュボードをブックマークし、新機能採用時期を四半期ごとにチェックする習慣をつけましょう。
- Container Queriesシリーズを順に追うと、
scroll-state()がなぜ登場したかの流れが掴めます。 - ポストトレーニングやモデルパイプラインに関心がある方は、Hugging Face TRL v1.0リリースまとめも併せてご覧ください。
まとめ
2026年のCSSは「できることが多すぎる」状態です。重要なのは何が使えるかではなく、何を使わなくてよいかを判断する感覚です。上記4項目のうち最低1つを次のスプリントで試験導入し、結果をチームWikiに共有してみてください。それが最も速い学習ループになります。