Web platform features that are finally safe to ship

Keeping up with the web platform is a constant battle. Browsers ship new capabilities every few weeks, and it's not always obvious when an experimental feature has reached the point where you can rely on it in production. The Chrome team has been working with other browser engines and the WebDX Community Group to define a clearer milestone: a feature is considered part of "Baseline" once it has been available across all major browser engines for two major versions.

That threshold is meant to signal that a feature is stable enough for most developers to adopt without worrying about breaking core experiences for a significant slice of users. Here are several features that have crossed that line and are ready for everyday use.

The <dialog> element for modals

Building accessible dialogs and modals has historically meant reaching for a library or carefully wiring up focus traps, ARIA attributes, and stacking contexts. The <dialog> element handles those details natively. You define the element and open it by calling the showModal() method:

<dialog id="d">
  <form method="dialog">
    <p>Hi, I'm a dialog.</p>
    <button>ok</button>
  </form>
</dialog>

<button onclick="d.showModal()">
  Open Dialog
</button>

Because focus management, tab tracking, and stacking context are baked into the element, you get these behaviors without custom JavaScript. This is worth reviewing if you maintain a custom modal or popup component.

Individual CSS transform properties

CSS transforms have long been written as a single shorthand combining translate, rotate, and scale into one declaration. Individual transform properties let you specify each of those separately:

.target {
  translate: 50% 0;
  rotate: 30deg;
  scale: 1.2;
}

This granularity becomes valuable when you're writing complex keyframe animations where you only want to animate one transform axis at a time—without having to restate the full transform value on every frame.

Viewport units that account for mobile toolbars

On mobile devices, the visible viewport changes as the browser's address bar and navigation toolbar appear and disappear. That makes it tricky to size elements relative to the actual visible area. The newer svh and lvh units give you explicit control: svh refers to the small viewport when toolbars are expanded, and lvh refers to the large viewport when they are retracted. These units make it easier to design layouts that adapt cleanly to shifting toolbar states.

Deep-copy with structuredClone

For years, the common workaround for deep-copying a JavaScript object was a combination of JSON.stringify and JSON.parse, which breaks on values that aren't JSON-serializable. The structuredClone function now provides a native, robust way to create a deep copy without losing those edge cases:

const original = {id: 0, prop: {name: "Tom"}}

/* Old hack */ 
const deepCopy = JSON.parse(JSON.stringify(original));

/* New way */
const deepCopy = structuredClone(original);

It's now a standard tool for any code that needs a true clone of an object graph without retaining references to the original.

Styling the :focus-visible state

The "focus ring" that appears when navigating with a keyboard is a critical accessibility feature, but it can be visually intrusive in click-driven interfaces. The :focus-visible pseudo-class lets you apply styles only when the browser determines the focus indication is necessary—typically when the user is navigating via keyboard:

/* focus with tab key */
:focus-visible {
    outline: 5px solid pink;
}

/* mouse click */
:focus:not(:focus-visible) {
    outline: none;
}

This lets you keep a polished visual design for mouse and touch users while preserving clear keyboard navigation indicators.

The TransformStream interface

The TransformStream interface from the Streams API enables composable data processing pipelines. Streams can be piped directly into one another, allowing you to transform data as it moves from source to destination—for example, compressing streaming data from one location before writing it elsewhere. This enables efficient processing without buffering entire payloads in memory.

What comes next

More features are continuing to reach interoperable status across all major browser engines. Community input through the WebDX Community Group shapes which features are prioritized next and how the Baseline criteria are refined. In the meantime, announcements are published when a feature becomes newly interoperable, with monthly overviews covering the full web platform from experimental features to newly stable ones.