NEW CAPABILITIES. PRACTICAL CONTEXT.THE OPENING COLLECTION / 2026

THE WORKBENCH / Useful Tomorrow

Browser Feature Explorer

Explore eight browser capabilities with primary documentation, fallback guidance, and a checklist for your own adoption decision.

Documentation snapshot: September 6, 2026. Follow the current compatibility links before adopting a feature. These notes do not claim a cross-browser test run.

8 of 8 features shown · 0 of 32 checks marked by you

Interface

Native dialog

Present a focused confirmation or short task in a modal window, with browser-managed modality through the dialog element.

Fallback: Provide the task as an ordinary linked page or visible section first. Offer modal presentation after support is detected, while keeping the original route usable.

Check showModal() separately from newer additions such as closedby and invoker commands. This entry does not assume those additions.

Read the documentation ↗
Check current compatibility ↗

Inspect the adoption checklist

Use showModal() when the surrounding page must become inert. Give the dialog an accessible name, a deliberate initial focus target, and an explicit close control.

  • The open attribute and show() create a non-modal dialog.
  • Native behavior still needs appropriate labeling, focus choices, and interaction testing.

Read the specification

Dialog element and attributes

Interface

Popover

Reveal brief contextual help or a small control panel above the page while allowing the rest of the page to remain interactive.

Fallback: Keep essential content inline or available through an ordinary link. Hide it behind a popover only when that control is usable; avoid leaving an inert toggle button.

Check the attribute, control button, and any JavaScript methods used. Hint popovers and interest invokers require their own checks.

Read the documentation ↗
Check current compatibility ↗

Inspect the adoption checklist

Connect a button to popover content with popovertarget. Use the auto state when outside-click and Escape dismissal fit the interaction.

  • A popover is non-modal; it does not make the surrounding page inert.
  • The API does not by itself implement menu semantics or arrow-key navigation.

Read the specification

Layout

Container size queries

Let a reusable card or component adapt to the space its parent provides, including narrow sidebars inside wide browser windows.

Fallback: Start with a flexible, readable layout outside @container. Add component refinements inside the query so ignored rules leave all content usable.

This entry covers inline-size queries. Check @container syntax and required values; style, scroll-state, and anchored queries are separate capabilities.

Read the documentation ↗
Check current compatibility ↗

Inspect the adoption checklist

Declare container-type: inline-size on an appropriate ancestor, then use @container size rules to adapt descendants.

  • A size query styles descendants based on an eligible ancestor, not the queried container itself.
  • Containment affects sizing; verify the container's dimensions in the actual layout.

Read the specification

@container syntax support

Motion

View transitions

Add visual continuity when a page changes state, such as moving between a compact list and a detailed view.

Fallback: Apply the content update immediately when the API is unavailable or reduced motion is requested. Navigation and state changes should not depend on animation finishing.

Same-document and cross-document transitions have different entry points. A detected startViewTransition() method does not establish cross-document support.

Read the documentation ↗
Check current compatibility ↗

Inspect the adoption checklist

For an in-page update, let startViewTransition() wrap the same update function the page can run directly.

  • Cross-document transitions need separate opt-in and same-origin navigation.
  • Animation does not replace focus management or announcements for changing content.

Read the specification

Cross-document @view-transition support

Layout

CSS anchor positioning

Position contextual content relative to a named element, with CSS options for trying another placement when space is tight.

Fallback: Keep the content in normal document flow, or use a simple existing placement. Put anchor-dependent positioning behind checks for the declarations actually used.

Check anchor-name, position-anchor, placement syntax, and overflow fallback properties individually. The anchor-name table is the first check, not a verdict on the module.

Read the documentation ↗
Check current compatibility ↗

Inspect the adoption checklist

Associate an element using absolute or fixed positioning with an anchor, then add the placement and overflow fallback properties the design needs.

  • A supported anchor-name declaration does not prove every positioning option works.
  • Anchoring determines geometry; popover behavior and accessibility semantics are separate.

Read the specification

position-anchor support

position-area support

position-try-fallbacks support

Using anchor positioning

Observation

ResizeObserver

Run a small update when an element's dimensions change, such as redrawing a chart after its surrounding panel resizes.

Fallback: Provide a usable initial rendering and CSS sizing. If needed, offer a manual refresh or limited window-resize update, documenting that it misses other element-size changes.

Check observe() options and the entry-size fields you read. Basic API presence does not guarantee every box measurement is available.

Read the documentation ↗
Check current compatibility ↗

Inspect the adoption checklist

Observe the relevant element and choose the measurement box the update actually needs. Disconnect observers when their component is removed.

  • Changing the observed size inside a callback can create a feedback loop.
  • The observer reports size changes, not arbitrary position or visibility changes.

Read the specification

observe() options support

Observation

IntersectionObserver

React when content crosses a viewport or scroll-container threshold, such as preparing an optional preview as it approaches view.

Fallback: Render essential content normally. Load optional material directly or provide a usable load button when observation is unavailable; keep pagination available for long lists.

Check the options used. Visibility tracking is a separate capability from basic intersection observation.

Read the documentation ↗
Check current compatibility ↗

Inspect the adoption checklist

Choose the correct root, margin, and threshold, then perform bounded work when an entry reaches the condition.

  • Basic intersection describes geometry, not proof that a person saw the content.
  • Notifications are asynchronous and threshold-based, not a per-pixel scroll timeline.

Read the specification

Forms

HTML form validation

Give people immediate feedback on missing or malformed form values using semantic input types and built-in constraints.

Fallback: Keep ordinary form submission and clear server-returned errors working without JavaScript. Validate submitted data on the server even when the browser has already checked it.

Check the actual input types, attributes, and validation methods used. A checkValidity() support result covers only that method.

Read the documentation ↗
Check current compatibility ↗

Inspect the adoption checklist

Start with labels, suitable input types, and constraints such as required. Use the Constraint Validation API when a custom rule needs client feedback.

  • Client validation can be bypassed and cannot enforce server rules.
  • form.submit() bypasses constraint validation; user submission or requestSubmit() follows a different path.

Read the specification

requestSubmit() behavior