The Web Platform in 2025 — Complete Guide: Container Queries, :has(), CSS Nesting, Subgrid, Popover API, Anchor Positioning, WebGPU, WASI, Speculation Rules, and Baseline 2024-2025 — Season 6 Ep 5

Prologue · When the Platform Grows, the Framework Gets Lighter

Between 2014 and 2020, the reason we needed React, Vue, and Angular was that browsers fell so far short. Components, state management, animation, routing, layout, interaction — all of it had to be solved in JS.

2024-2025 is different. The browser does most of it.

• Container Queries make a component responsive on its own
• :has() gives you parent-based selection without JS
• CSS Nesting and Subgrid reduce the need for SCSS
• The Popover API and Dialog minimize the need for a modal library
• Anchor Positioning makes Floating UI native
• View Transitions make page transitions native
• WebGPU brings high-performance graphics and ML
• Speculation Rules brings prerender and prefetch

We still use Next.js and React, but "whatever the platform can carry, give to the platform" is the principle of 2025. This post is the map for that.

Chapter 1 · Baseline — The New Language of Compatibility

What Is Baseline?

A labeling system for browser feature compatibility, created by the Web DX Community Group in 2023-2024. It answers the question, "Is this feature safe to use right now?"

Three Levels

Baseline Newly available

• Has landed in the most recent major browsers (Chrome, Edge, Firefox, Safari)
• Targets the latest versions

Baseline Widely available

• 30 months have passed since the state above
• Effectively supported by every active browser
• Safe to use with confidence

Limited availability

• Only one or two major browsers support it
• Use with caution in production

Using It in Practice

• MDN, caniuse, and web.dev display Baseline labels
• Next.js, Astro, and Vite have introduced options like target: baseline-2024
• Declare in your internal coding guide: "no polyfills only for Baseline widely available"

Why It Matters

• Replaces vague criteria like "IE support" or "modern browsers"
• Decisions inside the team become fast and unambiguous
• A quality bar for production stability and PWAs

Chapter 2 · Container Queries — The Responsive Revolution

The Traditional Problem

The media query @media is measured against the whole viewport. But when the same card component sits in a sidebar sometimes and in the main column at other times, its size differs. Even at the same viewport.

The Fix: @container

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

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

Now the card layout is decided by the card grid's own width.

Units

• cqw, cqh: container width/height
• cqi, cqb: inline/block
• cqmin, cqmax

Support in 2025

• Chrome 105+, Safari 16+, and Firefox 110+ are all Baseline Widely available
• Effectively a default tool

Usage Patterns

(1) Self-responsive components

• Independent of where they are reused

(2) Style Queries (2024, Chrome/Edge)

• @container style(--theme: dark) — a condition based on a parent's style property

(3) Viewport plus container together

• Media queries for the page layout, container queries for the components

Chapter 3 · :has() — The Arrival of the Parent Selector

Why It Is a Revolution

CSS has always been a selector that flowed only downward. Styling a parent based on its children required JS. :has() removes that limit.

Examples

(1) Styling a parent by whether a child exists

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

(2) Styling everything by the state of a child

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

(3) Sibling relationships

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

Support

• Chrome 105+, Safari 15.4+, Firefox 121+ — Baseline Widely
• The performance worries of the past have been resolved

Real-World Impact

• The JS that manipulated parent classes can be deleted in bulk
• Interaction-state UI becomes far more concise
• Many of a React component's "state props" move into CSS

Chapter 4 · Native CSS Nesting

Until Now

• Nesting via SCSS, Less, or Stylus
• Dependent on build tooling, with a learning curve

Native Nesting in 2023-2024

.card {
  padding: 1rem;

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

  &:hover {
    background: #f0f0f0;

    & .title { color: #333; }
  }

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

Watch Out

• The latest spec allows the & selector to be omitted (2024 revision)
• Be careful about mixing it with the old syntax (& )
• Fall back by transpiling with PostCSS Preset-Env

Support

• Chrome 120+, Safari 17.2+, Firefox 117+ — Baseline 2023-2024

What It Means

• The need for SCSS drops sharply
• Dependence on CSS-in-JS drops
• The revival of vanilla CSS

Chapter 5 · CSS Subgrid

The Limits of Traditional Grid

• Putting a child grid inside a parent grid still leaves rows and columns unaligned
• Aligning card titles, bodies, and CTAs is hard

Subgrid Solves It

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

.child {
  display: grid;
  grid-template-columns: subgrid; /* inherit the parent grid */
}

Now the child grid snaps to the parent grid's tracks.

Use Cases

• Automatic alignment of title, body, and footer across a card list
• Multi-column forms
• Masonry layouts

Support

• Firefox 71+ (supported since 2019), Safari 16+, Chrome 117+ — Baseline 2023

Chapter 6 · Popover API and the Dialog Element

Problems With Traditional Modals

• Focus management by hand
• Scroll locking in JS
• ESC-to-close by hand
• Accessibility ARIA written yourself

<dialog> (HTML5)

• Both modal and non-modal
• Native focus trap
• showModal() / close() methods
• Closes on ESC automatically
• Styleable ::backdrop

The Popover API (2024-2025)

<button popovertarget="menu">Menu</button>
<div id="menu" popover>
  <ul>
    <li>Item 1</li>
    <li>Item 2</li>
  </ul>
</div>

• A popover from a single popover attribute
• Rendered in the top layer automatically (no z-index worries)
• Auto-hide (outside click, ESC)
• Manual control with popover="manual"

Support

• Chrome 114+, Safari 17+, Firefox 125+ — Baseline 2024

Practical Impact

• Less need to reach for Headless UI or Radix Dialog/Popover
• Native plus a little CSS/JS is enough

Chapter 7 · CSS Anchor Positioning

The Problem: Floating UI

Placing a tooltip, dropdown, or popover exactly relative to a given element is complicated.

• A library like Floating UI (Popper.js) is mandatory
• JS has to recalculate on resize and scroll

The Fix: CSS Anchor Positioning (2024-)

<button id="btn">Click</button>
<div popover style="position-anchor: --btn;">
  Tooltip
</div>

#btn { anchor-name: --btn; }

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

• Anchor-based positioning in CSS alone
• Automatic repositioning (fallback)
• Performance and accessibility built in

Support (April 2025)

• Chrome 125+: stable
• Safari: in development (second half of 2025)
• Firefox: in development

Impact

• Less use of Popper and Floating UI
• Simpler React tree structure
• That said, a polyfill is still needed (until Safari catches up)

Chapter 8 · Web Components — Where They Stand in 2025

The Three Basics

• Custom Elements
• Shadow DOM
• HTML Templates

Maturing Through 2024-2025

(1) Declarative Shadow DOM

• Includes the shadow DOM when rendering on the server
• SSR becomes possible

(2) Form-associated Custom Elements

• Integrate naturally into standard forms
• formAssociated = true, the ElementInternals API

(3) The CSS :state() pseudo-class

• Select custom states from CSS

Framework Integration

• React 19 improves Custom Elements support (distinguishing attributes from props)
• Lit and Stencil have matured
• Vue and Svelte integrate naturally

An Honest Assessment

Strengths

• Framework-neutral (design systems, embedded widgets)
• Longevity (a browser standard)

Limits

• No ecosystem on the level of React components
• SSR and hydration are complicated
• Mostly confined to shared libraries and embedded widgets

Where They Fit

• A "Button/Icon library" shared across several teams
• Widgets embedded on external sites (comments, chat)
• Plugins for Shopify, WordPress, and the like

Chapter 9 · Where WebGPU Stands

The Limits of WebGL

• Built on OpenGL ES, an aging structure
• Limited parallel computing
• Not enough for games or AI

WebGPU (2023-)

• A modern GPU API (on the level of Vulkan, Metal, DX12)
• Compute shader support → general-purpose GPU computing
• One API across multiple operating systems

Major Uses in 2024-2025

(1) Running AI/ML in the browser

• Transformers.js: browser inference for Whisper, Llama, and more
• ONNX Runtime Web: GPU acceleration
• MLC-LLM: even a 7B model, in the browser

(2) High-performance graphics

• WebGPU-based 3D engines (Three.js, Babylon.js)
• Games and virtual exhibitions

(3) Data visualization

• Large point clouds and performance beyond WebGL

Support

• Chrome 113+ and Edge 113+ are stable
• Safari 18+ and Firefox Nightly (in progress through 2025)

Limits

• Mobile support is still partial
• Memory management is complicated

Chapter 10 · File System Access API and Other Local Capabilities

File System Access API

• Open and save local files directly from the browser
• Goes beyond the traditional <input type="file"> to keep accessing and modifying
• Essential for apps like Photopea, VS Code Web, and Figma

Major New APIs in 2024-2025

(1) An upgraded Clipboard API

• Supports images and rich text

(2) Web Share API

• The OS-native share sheet

(3) Wake Lock API

• Prevents the screen from sleeping (cooking and meeting apps)

(4) Screen Capture and WebCodecs

• Low-level video and audio

(5) Compression Streams

• Native gzip and deflate

(6) Web Locks

• Cross-tab mutexes and resource coordination

Limits

• Some require a PWA or a settings change
• Support varies between Safari and Firefox

Chapter 11 · WebAssembly and WASI in 2025

Where WASM Is Now

• Near-native performance in most mobile and desktop browsers
• Fast interop with JS (WASM SIMD, reference types, exception handling)
• Languages: Rust, Go, C/C++, AssemblyScript, Zig, with Kotlin and Swift experimental

WASI (WebAssembly System Interface)

The standard for running WASM outside the browser and on the server.

• WASI Preview 2 (2024) — the component model
• The wasmtime, wasmer, and WasmEdge runtimes

Real-World Uses

(1) Serverless edge

• Cloudflare Workers, Fastly Compute@Edge, Vercel WASM
• Cold start, isolation, multiple languages

(2) Plugin systems

• Figma Plugins, Shopify Functions, Envoy Proxy
• Safe isolation of user code

(3) Heavy computation inside the browser

• Image and video editing, ML inference, emulators

Adoption in Korea

• Naver Whale: WASM-based extensions
• KakaoTalk Web: WASM for some features
• Toss: considering WASM for security and core logic

Chapter 12 · Speculation Rules API

The Goal

• Load the page the user will go to next, in advance
• A standard for prerender and prefetch

Example

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

Modes

• prefetch: fetches resources only, does not execute
• prerender: renders everything (fastest, but costlier)

Status in 2024-2025

• Chrome 121+ and Edge 121+ are stable
• Safari and Firefox are in development
• Chrome Prefetch Hints gives data-driven automatic suggestions

Real-World Use

• Next.js and Astro are considering automatic injection from the backend
• Large news and e-commerce sites are starting to use it

Watch Out

• Cost (CPU, network)
• The "phantom visit" problem in analytics tools

Chapter 13 · In Practice · The "Platform First" Checklist

Check this before reaching for a framework or library when you build a new component or feature.

Checklist Items

• Responsive: can Container Queries do it?
• State styling: with :has() or :focus-within?
• Modals and popovers: <dialog> or the Popover API?
• Tooltips and dropdowns: Anchor Positioning?
• Form validity: :user-invalid and :user-valid?
• Side sheets: <details> plus styling?
• Files: File System Access?
• Counters and changing numbers: CSS @property animation?
• Scroll effects: Scroll-driven Animations?
• Page transitions: View Transitions?

Order of Judgment

1. Does the web platform have this built in?
2. Is it Baseline Widely supported?
3. If not, can a lightweight library replace it?
4. If you still need it, then a framework component

Chapter 14 · Next Up — Season 6 Ep 6: "Performance and Core Web Vitals 2025"

Using web platform features well is using performance well. Ep 6 covers Core Web Vitals and performance overall.

• LCP, CLS, INP (the successor to FID)
• Real user monitoring vs. synthetic testing
• The critical rendering path, LCP optimization
• Putting the JS bundle on a diet (Rollup, esbuild, swc)
• Image optimization (Next/Image, Astro Image, AVIF)
• Font optimization (font-display, variable fonts, subsetting)
• Caching strategy (Cache-Control, Service Worker)
• Edge, CDN, HTTP/3
• Vercel Speed Insights, CrUX, PageSpeed
• Low-power mobile performance in 2025
• The network characteristics of Korean users (subways, 5G)

"Performance is not a feature. It is the condition of every feature."

See you in the next post.

Epilogue · A 12-Point Checklist

1. Do you decide feature usage on the Baseline Widely standard?
2. When you need responsiveness, do you consider Container Queries first?
3. Do you use :has() for parent-based styling?
4. Is your CSS managed with Nesting rather than a build tool?
5. Do you use Subgrid for complex layouts?
6. Do you build modals and popovers with native APIs?
7. Do you position tooltips and dropdowns with Anchor Positioning?
8. Do you use Web Components for shared libraries?
9. Are you exploring the opportunities in WebGPU (AI, visualization)?
10. When you need local capabilities (files, system), does a Platform API come first?
11. Have you evaluated prefetch and prerender via Speculation Rules?
12. Do you apply the "platform first" checklist to every new component?

"A good engineer knows what the platform can do. A great engineer knows when to hand work to the platform and when to build it."

— Season 6 Ep 5, Fin.