LabHub

ブログ

ウェブプラットフォーム 2025 完全攻略:Container Queries・:has()・CSS Nesting・Subgrid・Popover API・Anchor Positioning・WebGPU・WASI・Speculation Rules・Baseline 2024-2025 — Season 6 Ep 5

한국어English日本語中文

プロローグ · プラットフォームが大きくなればフレームワークは軽くなる

2014-2020 年に React・Vue・Angular が必要だった理由は、ブラウザがあまりにも足りなかったからだ。コンポーネント・状態管理・アニメーション・ルーティング・レイアウト・インタラクションのすべてを JS で解決しなければならなかった。

2024-2025 年は違う。ブラウザがほとんどをやってくれる

Next.js・React は今も使うが、2025 年の原則は 「プラットフォームに任せられるものはプラットフォームに」 だ。今回の記事はその地図。

第1章 · Baseline — 互換性の新しい言語

Baseline とは?

2023-2024 年に Web DX Community Group が作ったブラウザ機能の互換性ラベル体系。「この機能は今すぐ使っても安全か?」に答える。

3 段階

Baseline Newly available

Baseline Widely available

Limited availability

実戦での使い方

なぜ重要か

第2章 · Container Queries — レスポンシブの革命

従来の問題

メディアクエリ @mediaビューポート全体 が基準。しかし同じカードコンポーネントが、あるときはサイドバー、あるときはメインに配置されるとサイズが変わる。ビューポートは同じでも。

解決: @container

.card-grid {
  container-type: inline-size;
  container-name: grid;
}

@container grid (min-width: 600px) {
  .card { display: flex; }
}

これでカードグリッド 自体の幅 を基準にカードのレイアウトが決まる。

単位

2025 年の対応状況

使用パターン

(1) 自己完結型のレスポンシブコンポーネント

(2) Style Queries (2024 Chrome/Edge)

(3) ビューポート + コンテナの組み合わせ

第3章 · :has() — 親セレクタの到来

なぜ革命なのか

CSS はいつも 下方向にだけ 下りていくセレクタだった。子を基準にした親のスタイリングには JS が必須。:has() がこの制限を取り払った。

使用例

(1) 子の有無による親のスタイル

.card:has(img) { padding-top: 0; }
.form:has(input:invalid) { border: 1px solid red; }

(2) 子の状態による全体のスタイル

body:has(dialog[open]) { overflow: hidden; }

(3) 兄弟関係

label:has(+ input:focus) { color: blue; }

対応状況

実戦でのインパクト

第4章 · CSS Nesting のネイティブ化

これまで

2023-2024 のネイティブ Nesting

.card {
  padding: 1rem;

  & .title {
    font-size: 1.5rem;
  }

  &:hover {
    background: #f0f0f0;

    & .title { color: #333; }
  }

  @media (min-width: 768px) {
    padding: 2rem;
  }
}

注意

対応状況

意味するもの

第5章 · CSS Subgrid

従来の Grid の限界

Subgrid が解決する

.parent {
  display: grid;
  grid-template-columns: repeat(3, 1fr);
}

.child {
  display: grid;
  grid-template-columns: subgrid; /* 親グリッドを継承 */
}

これで子の grid が親の grid のトラックに揃う。

ユースケース

対応状況

第6章 · Popover API・Dialog Element

従来のモーダルの問題

<dialog> (HTML5)

Popover API (2024-2025)

<button popovertarget="menu">メニュー</button>
<div id="menu" popover>
  <ul>
    <li>項目 1</li>
    <li>項目 2</li>
  </ul>
</div>

対応状況

実戦での影響

第7章 · CSS Anchor Positioning

問題: フローティング UI

ツールチップ・ドロップダウン・ポップオーバーを特定の要素を基準に 正確に配置 するのは複雑。

解決: CSS Anchor Positioning (2024-)

<button id="btn">クリック</button>
<div popover style="position-anchor: --btn;">
  ツールチップ
</div>
#btn { anchor-name: --btn; }

[popover] {
  position: absolute;
  top: anchor(--btn bottom);
  left: anchor(--btn left);
}

対応状況 (2025 年 4 月)

インパクト

第8章 · Web Components の 2025 年の現在地

基本の 3 要素

2024-2025 年の成熟

(1) Declarative Shadow DOM

(2) Form-associated Custom Elements

(3) CSS :state() 疑似クラス

フレームワークとの統合

現実的な評価

長所

限界

適した用途

第9章 · WebGPU の現在地

WebGL の限界

WebGPU (2023-)

2024-2025 の主な用途

(1) AI/ML のブラウザ実行

(2) 高性能グラフィックス

(3) データ可視化

対応状況

限界

第10章 · File System Access API・その他のローカル機能

File System Access API

2024-2025 の主な新 API

(1) Clipboard API の高度化

(2) Web Share API

(3) Wake Lock API

(4) Screen Capture・WebCodecs

(5) Compression Streams

(6) Web Locks

限界

第11章 · WebAssembly・WASI 2025

WASM の現在

WASI (WebAssembly System Interface)

ブラウザの外・サーバーで WASM を実行するための標準。

実戦での使用

(1) Serverless エッジ

(2) プラグインシステム

(3) ブラウザ内の重い演算

韓国での適用事例

第12章 · Speculation Rules API

目的

<script type="speculationrules">
{
  "prerender": [
    { "source": "list",
      "urls": ["/next-page", "/likely-next"] }
  ],
  "prefetch": [
    { "source": "document",
      "where": { "href_matches": "/articles/*" } }
  ]
}
</script>

モード

2024-2025 の現況

実戦での使用

注意

第13章 · 実戦 · 「プラットフォーム優先」チェックリスト

新しいコンポーネント・機能を作るとき、フレームワーク・ライブラリの前に 確認する。

チェック項目

判断の順序

  1. ウェブプラットフォームに標準機能はあるか?
  2. Baseline Widely 対応か?
  3. なければ、軽量ライブラリで代替できるか?
  4. それでも必要なら、フレームワークのコンポーネント

第14章 · 次回予告 — Season 6 Ep 6:「パフォーマンス・Core Web Vitals 2025」

ウェブプラットフォームの機能をうまく使うことは、パフォーマンス をうまく使うことだ。Ep 6 は Core Web Vitals とパフォーマンス全般。

「パフォーマンスは機能ではない。すべての機能の条件だ」

次の記事で会おう。

エピローグ · チェックリスト 12

  1. Baseline Widely を基準に機能の使用を決めているか?
  2. レスポンシブが必要なとき Container Queries を先に検討しているか?
  3. 親要素ベースのスタイルに :has() を活用しているか?
  4. CSS がビルドツールなしで Nesting で管理されているか?
  5. 複雑なレイアウトに Subgrid を使っているか?
  6. モーダル・ポップオーバーを ネイティブ API で実装しているか?
  7. ツールチップ・ドロップダウンの位置を Anchor Positioning で?
  8. Web Components を 共有ライブラリ に活用しているか?
  9. WebGPU の機会(AI・可視化)を探索しているか?
  10. ローカル機能(ファイル・システム)が必要なら Platform API が先か?
  11. Speculation Rules でプリフェッチ/プリレンダーを検討したか?
  12. 「プラットフォーム優先」チェックリストを 新しいコンポーネントごとに 適用しているか?

「良いエンジニアはプラットフォームの能力を知っている。 偉大なエンジニアはいつプラットフォームに任せ、いつ自分で作るかを知っている。」

— Season 6 Ep 5, Fin.

コメント

まだコメントはありません。

ログインするとコメントできます