CSS :open reaches Baseline 2026, giving one selector for open UI states

The CSS :open pseudo-class has reached Baseline 2026. According to a dev.to write-up citing MDN, the selector became newly available across the latest versions of the core browsers in May 2026, and it gives developers one semantic way to style elements that are currently open: disclosure widgets, dialogs, select pickers and picker-backed inputs such as date and color fields.

A single selector for a state that needed workarounds

Until now, open-state styling depended on the element in question. Disclosures were handled with details[open], dialogs likewise expose their state through an open attribute, and native pickers — a select with its dropdown showing, for example — had no general-purpose equivalent at all. The new pseudo-class expresses the state directly: details:open > summary targets the summary of an open disclosure without reaching for the attribute, and the same keyword works for every control that has an open/closed notion.

Native pickers are the main win

The dev.to author singles out the native select as the most interesting case. While a select's picker is displayed, select:open can restyle the control with a highlight border or focus ring, something older CSS could not target consistently. Paired with :has(), the effect extends to containers: .field:has(select:open) can change a wrapper's background the moment its child select opens, removing the JavaScript class-toggling this pattern usually required.

The same selector can match inputs while a browser-provided picker is open, including date and color controls where supported. Because picker presentation varies per platform, the author recommends testing on real operating systems rather than trusting desktop screenshots alone. One design note from the piece: keep the visual change subtle so opening a picker does not cause nearby content to jump.

Fallbacks and feature detection

Older browsers still exist, so production stylesheets should keep fallbacks wherever the open-state look matters. For details and dialog, the [open] attribute selector remains dependable because those elements reflect their state through that attribute; the two selectors can coexist in a single rule during migration.

For enhancements with no simple fallback — the select picker case — the suggested approach is @supports selector(:open), applied only to the new styling, while the closed appearance stays complete and accessible on its own.

Things :open is not

The pseudo-class is distinct from :popover-open, which covers popover elements that are currently showing. The dev.to post draws the line clearly: use :open for controls with a semantic open/closed state, and :popover-open for a popover in its showing state.

Open also does not guarantee visible. A details element can carry an open state while an ancestor hides it entirely, so the selector reports state rather than what the user can actually see — the author warns against treating it as a visibility or layout check.

Animations need care too. An open-state selector can drive a transition, but not every element's hidden-to-visible behaviour is animatable, and some elements stop rendering content the moment they close, which can prevent the reverse transition from appearing as expected. Testing should cover closing as well as opening, with reduced-motion preferences respected.

Why it matters

:open is a small addition with a broad effect: it gives several native controls a shared vocabulary for their active state. That can remove JavaScript classes from simple visual changes, finally allow consistent styling of native picker states, and make selectors read like the interface behaviour they describe.

With Baseline 2026 availability, it is practical to ship now as an enhancement, while [open] fallbacks and @supports cover older browsers. The migration path the author suggests is straightforward: keep [open] fallbacks for existing details and dialogs, add :open for select and picker enhancements, isolate new styling behind feature detection, and test keyboard interaction, zoom and multiple operating systems.

As the piece stresses, the browser supplies the state — semantics, accessible names, visible focus and clear communication of that state remain the developer's job.