2026年版 JavaScript頼みをやめる CSS新機能4選 :has スクロール駆動 View Transitions Anchor を実務で使い切る

Web制作あるあるです。「これCSSだけで行けそうだけど、結局JSを書いた方が早いよね」で、気付けばイベントリスナーが増殖し、状態管理が絡まり、保守で胃が痛くなる。

でも2025年以降のCSSは、ただの見た目担当ではなくなってきました。UIの条件分岐、スクロール連動、画面遷移のなめらかさ、要素にひも付く配置まで、従来はJavaScriptに寄せていた領域がCSS中心でも組めるようになっています。

この記事は、参考記事の内容を土台にしつつ、実務で「使えるかどうか」の判断軸と、導入時の落とし穴、そして2026年時点のアップデート感を混ぜてリライトしたものです。忙しい人でも流し読みで要点が拾えるように、結論から順番に置いていきます。

結論 まず止めるべきは 何でもJSで解決する癖

最初に言い切ります。止める必要があるのは「UIの表現や条件分岐を、反射的にJavaScriptでやる運用」です。

理由は単純で、長期運用の現場ほど負債の伸びが早いからです。特に次の3パターンは増えがちです。

• DOM監視してclassを付け替える
• スクロール量を計測してアニメーションを同期する
• ポップアップやツールチップをDOM構造に縛って配置する

これらが全部ダメという話ではありません。ただ、CSS側に素直な機能があるのに、慣れでJSに寄せるとコストが跳ねます。バグ調査が難しい、アクセシビリティ対応が後追いになる、パフォーマンスが劣化しやすい。結果として「早く作ったはずなのに、後で遅くなる」状態になりやすいです。

CSSに寄せるメリット

• コード量が減り、読む場所が減る
• 状態がDOMとCSSで完結しやすく、破綻しにくい
• スクロールやアニメの同期が軽くなりやすい

CSSに寄せるデメリット

• 新機能はブラウザ差が残ることがある
• フォールバック設計をサボると事故る
• チームに知識差があるとレビューで止まりやすい

なので実務の正解は「全部CSSでやる」ではなく、CSSで済む所はCSSに任せ、難しい所だけJSにする。その判断が上手い人ほど、なぜか納期も保守も強いです。

2026年に押さえたい CSS新機能4選 全体像

今回扱うのは次の4つです。

• :has() 擬似クラス 親や前の兄弟を条件付きで選べる
• スクロール駆動アニメーション animation-timeline view-timeline scroll-timeline
• View Transitions API 画面状態やページ遷移をなめらかに
• CSS Anchor Positioning anchor-name anchor() ひも付け配置

どれも「JSの出番を減らす」方向に効きます。ただし導入の順番があります。体感では :has() が一番即戦力、次にAnchor、アニメは案件次第、View Transitionsは体験価値が高いが設計も大事、という並びです。

1 :has() 親を選べる つまり条件分岐のCSSができる

:has() は「その要素が特定の子要素や条件を持つなら、この要素にスタイルを当てる」という書き方ができます。これが何を意味するかというと、今までJSでやっていた「中身を見て親にclassを付ける」がCSSだけで済む場面が増えます。

やり方 基本形は 親:has(条件)

.card:has(img) {
  border: 2px solid #2a7;
}

.form:has(input:invalid) {
  outline: 2px solid #d33;
}

画像があるカードだけ強調、入力エラーがあるフォームだけ目立たせる。どちらも実務のあるあるです。しかもJSで監視しなくていい。

実務で効く例1 画像ありカードだけレイアウトを変える

.card {
  display: grid;
  gap: 0.75rem;
}

.card:has(img) {
  grid-template-columns: 120px 1fr;
  align-items: start;
}

画像がないカードは縦積み、画像があるカードは2カラム。こういう分岐は、CMS案件ほど頻出です。

実務で効く例2 チェック済みの時だけ親を装飾する

.item:has(input[type="checkbox"]:checked) {
  background: #f6fbff;
}

.item:has(input[type="checkbox"]:checked) .label {
  font-weight: 700;
}

JSでcheckedを拾ってclassを付け替えていた所が、そのままCSSに寄ります。地味ですが保守が軽くなります。

なぜ止める必要があるのか :has() があるのにJS監視を続けると損

DOMの変化を監視してclassを付ける実装は、事故りやすいポイントが多いです。

• 動的に挿入された要素の拾い漏れ
• バリデーション状態の同期漏れ
• クラス名の増殖と命名の破綻

:has() に寄せると、この手の不具合がそもそも起きにくい構造になります。

メリット

• JSの条件分岐が減る
• CSSだけで完結するので意図が読める
• フォームUIの体験を作り込みやすい

デメリット 注意点

• 複雑な条件を深く書くと、スタイルの評価コストが増える可能性がある
• 古いブラウザを強く意識する案件ではフォールバックが必要

フォールバックの現実解 @supports selector を使う

/* :has() が使える環境だけ適用 */
@supports selector(.x:has(.y)) {
  .card:has(img) {
    border: 2px solid #2a7;
  }
}

使えない環境では「従来どおりclassを付けるJS」にしてもいいし、そもそも装飾を諦める判断でもいい。重要なのは、落ちても壊れないことです。

2 スクロール駆動アニメーション JSで測る時代を少しずつ卒業する

スクロール連動は、昔から定番です。フェードイン、パララックス、進捗バー。これまではIntersection Observerやscrollイベントで実装するのが主流でした。

そこで登場するのが、スクロールの進行をタイムラインとして扱う仕組みです。ざっくり言うと「スクロール量を計測してJSでアニメを進める」ではなく「CSSがスクロールの進行度を受け取ってアニメを進める」という方向になります。

やり方 view-timeline と animation-timeline の基本

.reveal {
  animation-name: fadeUp;
  animation-duration: 1s;
  animation-timeline: view();
  animation-range: entry 20% cover 40%;
}

@keyframes fadeUp {
  from { opacity: 0; transform: translateY(12px); }
  to   { opacity: 1; transform: translateY(0); }
}

これで「要素が見え始めてから表示されるまでに合わせてアニメが進む」形を作れます。JSで交差判定してclassを付けるより、設計がシンプルになります。

実務で効く例 進捗バーをCSSで動かす

.scroller {
  height: 280px;
  overflow: auto;
  scroll-timeline: --t y;
}

.bar {
  transform-origin: left center;
  animation: grow linear both;
  animation-timeline: --t;
}

@keyframes grow {
  from { transform: scaleX(0); }
  to   { transform: scaleX(1); }
}

UIとして分かりやすい割に、JSが不要になりやすい部類です。

なぜ止める必要があるのか スクロールイベント地獄から抜ける

スクロール連動をJSでやると、次の課題が出がちです。

• 端末によって処理落ちする
• 描画タイミングと同期がずれてカクつく
• 条件分岐が増え、保守が難しくなる

スクロール駆動は、ブラウザ側が進行を管理する方向なので、実装者が頑張り過ぎなくてよくなります。

メリット

• JSの監視コードが減る
• 宣言的に書けて読みやすい
• 効果が小さくても体験が上がる

デメリット 注意点

• ブラウザ対応がそろっていない機能がある
• 複雑な演出や同期は依然としてJSが強い

実務の落とし所 まずは装飾系だけCSS駆動に寄せる

いきなりパララックス全部を置き換えるのは危険です。おすすめは、フェードインや進捗バーなど「壊れても致命傷にならない演出」から導入することです。

3 View Transitions API 画面が変わる瞬間を気持ちよくする

ページ遷移や表示切替が唐突だと、ユーザーは一瞬だけ迷子になります。View Transitionsは、その切替を自然に見せるための仕組みです。

SPAのDOM更新だけでなく、MPAのページ遷移でも使える流れが進んでいます。つまり「サイト全体がぬるっと動く」が標準の道具になりつつあります。

やり方 同一ドキュメントでの基本形

const el = document.querySelector(".panel");
document.querySelector("#btn").addEventListener("click", () => {
  document.startViewTransition(() => {
    el.classList.toggle("is-b");
  });
});

CSS側は疑似要素で旧状態と新状態のアニメを指定できます。

::view-transition-old(root) {
  animation: fadeOut 0.25s ease-out both;
}
::view-transition-new(root) {
  animation: fadeIn 0.25s ease-out both;
}

@keyframes fadeOut { from { opacity: 1; } to { opacity: 0; } }
@keyframes fadeIn  { from { opacity: 0; } to { opacity: 1; } }

この構成にすると、画面の切替が「機械的」から「人間に優しい」寄りになります。

なぜ止める必要があるのか 遷移演出を場当たりで作ると破綻する

従来の遷移演出は、ページごとにフェード用のオーバーレイを用意して、JSで表示して、遷移して、次ページで解除して、という実装が多かったです。これ、トラブルの温床になります。

• 戻る操作でオーバーレイが残る
• 遷移速度が端末差でズレる
• アクセシビリティ配慮が漏れる

View Transitionsに寄せると「遷移というイベント」をブラウザが扱う前提になるので、無理やり感が減ります。

メリット

• 遷移が自然になり、体感品質が上がる
• ページ構造を大きく変えずに導入できることがある
• 演出が整理され、増殖しにくい

デメリット 注意点

• ブラウザ差が残るため、未対応時の見え方を許容する必要がある
• 凝った共有要素遷移は設計が必要

フォールバック 未対応なら何もしないが正解になりやすい

View Transitionsは「なくても動く」設計が作りやすいです。未対応環境では普通に切り替わるだけ。それでOKにすると、導入の心理的ハードルが下がります。

4 CSS Anchor Positioning ツールチップやメニューを親子構造から解放する

ドロップダウン、ツールチップ、ポップオーバー。これらは「基準となる要素の近くに出したい」のに、HTML構造の都合で配置がぐちゃぐちゃになりやすい部品です。

Anchor Positioningは、要素に名前を付けて、別要素をその位置にひも付ける考え方です。親子関係に依存せず配置できるので、DOM設計が楽になります。

やり方 anchor-name と anchor() でひも付ける

.btn {
  anchor-name: --menu-anchor;
}

.menu {
  position: absolute;
  top: anchor(--menu-anchor bottom);
  left: anchor(--menu-anchor left);
}

これで「ボタンのすぐ下にメニュー」がCSSで書けます。JSでgetBoundingClientRectして計算していた世界が、少しずつ薄くなります。

なぜ止める必要があるのか 位置計算JSは保守で必ず効いてくる

座標計算系のJSは、やる事が多いです。スクロール、リサイズ、フォントサイズ変更、表示領域からはみ出す時の反転。しかも全部テストが必要です。

Anchor Positioningには、はみ出し時のフォールバック設計を作る考え方も含まれています。つまり「UI部品の宿命」を仕様側が正面から扱い始めています。

メリット

• DOMの都合で配置が崩れる問題が減る
• 位置計算のJSが減りやすい
• コンポーネント設計が素直になる

デメリット 注意点

• 対応状況が揃っていない場合があるので、段階導入が必要
• 既存のポップオーバー実装と共存設計が必要なことがある

フォールバック @supports で未対応なら従来方式へ

@supports (anchor-name: --a) {
  .btn { anchor-name: --menu-anchor; }
  .menu {
    position: absolute;
    top: anchor(--menu-anchor bottom);
    left: anchor(--menu-anchor left);
  }
}

未対応時は、従来どおり親をposition: relativeにしてabsolute配置でもOKです。要するに、壊れない道を残しておくのが大事です。

導入の順番 実務で安全に勝つロードマップ

Step1 :has() を小さく入れる

カードやフォームなど、影響範囲が限定される所から。装飾レベルで導入し、未対応時に見た目が少し落ちるだけにする。

Step2 Anchor をツールチップなどで試す

最初は社内ツールやLPなど、影響が限定される案件が向きます。位置計算JSが減るだけで、保守がかなり楽になります。

Step3 スクロール駆動は軽い演出から

フェードイン、進捗バーなど、壊れても致命傷にならない演出から。scrollイベントの監視を減らせると、パフォーマンスが安定します。

Step4 View Transitionsは価値が出る所だけ

一覧から詳細への遷移など、ユーザーが迷いやすいポイントで効きます。全部に入れるより「ここぞ」の方がコスパがいいです。

よくある勘違い CSSだけで全部できる はまだ言い過ぎ

ここは冷静に。CSSが進化しているのは本当ですが、全部を置き換えられるわけではありません。

• 複雑な状態管理（ロジックやデータ依存）はJSが必要
• 高度なアニメ制御や物理演算はJSの方が得意
• 対応ブラウザを厳密に揃える案件ではフォールバックが必須

だからこそ「止める必要がある」のは、CSSで済む所までJSで抱え込む姿勢です。必要な所にだけJSを使う方が、結果的に速いです。

まとめ 2026年のCSSは 実務の負債を減らす道具になった

• :has() で 条件分岐のスタイルをCSSに戻せる
• スクロール駆動で スクロールイベント地獄から抜けられる場面がある
• View Transitionsで 遷移を気持ちよくして迷子を減らせる
• Anchorで 位置計算のJSを減らし コンポーネントを素直にできる

新機能は万能ではありませんが、使い所が明確です。小さく入れて、壊れないフォールバックを用意し、成果が出たら広げる。この流れが一番安全です。

読者向けの追加Tips ついでに押さえると現場が楽になる

フォールバック設計は @supports を標準装備にする

新機能を使う時ほど、@supportsで守りを作ると安心です。「使える環境だけ効く」を前提にすると、導入が速くなります。

動きは prefers-reduced-motion で弱めるのが礼儀

スクロール連動や遷移演出を入れるなら、動きを減らしたい人への配慮もセットが安全です。

@media (prefers-reduced-motion: reduce) {
  * {
    animation-duration: 0.001ms !important;
    animation-iteration-count: 1 !important;
    transition-duration: 0.001ms !important;
    scroll-behavior: auto !important;
  }
}

CSSの新機能は Baseline と互換表を必ず見る

導入前に、対応状況を確認する癖を付けると事故が減ります。特にスクロール駆動とAnchorは、案件のターゲット環境次第で判断が変わりやすいです。