How Should Webflow Designers Use the New :open Pseudo-Class?

Two of the three browsers I test against shipped the CSS :open pseudo-class this month. Chrome 148 went stable on May 5, 2026. Safari 26.5 followed on May 11. The pseudo-class matches the four native HTML elements that have an open state, details, dialog, select, and input, and lets designers style that open state declaratively. For every B2B SaaS Webflow site I have shipped at Phoenix Studio, the FAQ accordion is the single most-styled component, and the toggle has historically required a JavaScript-driven is-open class. That is now optional. In this piece I walk through what :open is, where it works today, the actual Webflow Designer pattern that uses it, and the fallback path you still need for the third browser that has not shipped it yet.

What is the CSS :open pseudo-class?

The CSS :open pseudo-class is a selector that matches an element when it is in its open state. It applies to the native HTML elements that have an open state, which today are details, dialog, select, and input. The pseudo-class is defined in CSS Selectors Level 4 and shipped to stable in Chrome 148 on May 5, 2026 and Safari 26.5 on May 11, 2026.

The full spec is in the CSS Selectors Level 4 draft at the CSS Working Group. Mozilla maintains a complete MDN reference for the selector. For Webflow designers, the relevant detail is that :open matches the element's open state automatically, without any JavaScript class toggle, which means the style rules in the Designer can react to that state without a custom interaction.

Which elements does :open match in 2026?

As of May 2026, :open matches the details element when it is expanded, the dialog element when it is open, the select element when it is showing its picker, and the input element when it is showing a date or time picker. The pseudo-class is intentionally limited to native elements with a defined open state in the HTML specification. Custom components require a different state mechanism.

The narrow element list is the point. The pseudo-class is not a generic open-or-closed selector. It is a hook into specific elements that the browser already manages an open state for. For Webflow sites, the most common use is on details for accordions and on dialog for modals. Select picker styling is platform-dependent and limited by what the browser exposes. Input picker styling is similarly constrained. Designers planning a custom dropdown or popover should look at the broader Open UI work and the popover API, not :open.

How does :open replace the "is-open" class pattern in Webflow?

The is-open pattern in Webflow typically uses a Designer Interaction that adds an is-open class on click and removes it on a second click. The class then drives a style change on the parent or sibling. With :open on a native details element, the browser manages the open state, the pseudo-class drives the style change, and the Interaction is no longer needed for the toggle itself.

The Designer-side change is that the FAQ block uses a native HTML embed with a details element rather than a Designer div block with a custom interaction. The CSS for the open state lives in either an embedded style block or a site-wide custom code stylesheet. Variants and Interactions can still attach to the same component for hover and focus states, but the open-state toggle is now declarative and accessible by default. This is consistent with the broader pattern in component-scoped Interactions where the native element does the work and Webflow Interactions handle only what the platform does not.

Does :open work in production today across Chrome and Safari?

Yes for the latest Chrome and Safari versions. Chrome 148 stable rolled out on May 5, 2026, reaching most desktop and mobile Chrome installs within the standard rollout window. Safari 26.5 shipped on May 11, 2026, included in the iOS and macOS updates of that week. Older browser versions and any non-Chromium, non-WebKit browser do not yet support the pseudo-class.

For production use today, the practical assumption is that the majority of Chrome and Safari users have :open support, but a meaningful tail of older installs does not. Older Chrome installs typically update within four to six weeks of a stable release, so by mid-June 2026 the support picture across Chrome should be near-complete. Safari updates depend on the user updating their iOS or macOS version, which has historically lagged. For a B2B SaaS audience on managed corporate fleets, expect slower Safari adoption.

Where is Firefox on :open and what's the fallback strategy?

Firefox has not shipped the :open pseudo-class to stable as of May 2026. The feature is tracked but not yet flagged for release in a specific upcoming version. The fallback strategy is to use the native open attribute on details and a JavaScript-set class on dialog for Firefox users, with the :open pseudo-class taking over on Chrome and Safari.

The fallback CSS is straightforward. For details, write the open-state style rule against both details[open] and details:open. Both selectors target the same elements, and the browser uses whichever it understands. For dialog, the pattern requires a small JavaScript shim that adds a class on the dialog when it opens, and the open-state style rule targets both the class and :open. This double-target pattern is the standard cross-browser approach this quarter and keeps Firefox users on the same visual treatment as Chrome and Safari users.

How do you wire :open into a Webflow FAQ accordion?

Wire :open into a Webflow FAQ accordion by replacing the existing Designer accordion pattern with a Custom Embed containing a details element, a summary element for the question, and the answer content inside details. Add CSS rules in Page Settings or a global style block that target details[open] and details:open for the open state. Style the summary normally.

The Designer-side pattern looks like this in practice. Each FAQ item becomes a Custom Embed that contains a details element. The summary holds the question text, and the body of the details holds the answer paragraph. Style rules apply to the summary marker, the open-state background, and any rotation animation on a chevron icon. The whole accordion list lives inside a regular Webflow div block with the right gap and width treatment. There is no Interaction attached, no is-open class, and no JavaScript. The browser does the work.

Should you use native dialog over a custom modal in Webflow?

Yes, in most cases. The native dialog element is now well-supported across modern browsers, ships with built-in keyboard handling, focus trap, and backdrop styling, and pairs naturally with :open for declarative state styling. Custom modal patterns built from div blocks and JavaScript still work but reproduce accessibility behavior the browser already gives you for free.

The migration path from a custom Webflow modal to a native dialog is a short refactor. Replace the modal wrapper div with a dialog element inside a Custom Embed. Replace the open and close JavaScript with calls to showModal and close on the dialog reference. Style the open state with :open and the backdrop with ::backdrop. The total custom code drops, the accessibility behavior improves, and the Designer-side layout for the modal interior stays the same. Phoenix Studio's last three Webflow modals all went this direction in the last quarter.

What styling rules pair well with :open for accordions?

The styling rules that pair well with :open for accordions include a transition on max-height for smooth expand and collapse, a transform rotation on a chevron icon, and a background or border color change on the summary when open. CSS variables let these rules respond to the open state without duplicating the rule set across multiple selectors or class combinations.

The specific style block I use on most projects looks something like this in prose: target the chevron inside a summary, give it a transform rotate of zero degrees by default, and rotate it to 180 degrees inside details:open. Target the details body with a max-height of zero and an overflow hidden by default, and set max-height to a large value or to fit-content inside details:open. Add a transition on max-height to make the animation smooth. The complete style block is around fifteen lines of CSS and replaces what used to be a Designer Interaction plus a custom JavaScript handler.

How does :open interact with the Open UI popover and select work?

:open is a sibling to the broader Open UI work, which extends styling reach to popovers, customizable select elements, and other interactive components that historically required JavaScript. The pseudo-class itself handles the simple, native cases. Open UI handles the harder cases like a custom select picker or a popover anchored to a button.

For Webflow designers, the practical implication is that :open is the right tool for native details, dialog, select, and input elements, and the Open UI work is the right tool for more complex interactive patterns that need styling reach. The two are complementary. I expect the :open pseudo-class to be the right tool for at least the next year on most marketing sites, with the popover API and customizable select gradually taking over the more complex patterns as cross-browser support arrives. This pattern of native elements gaining design hooks is the same one I tracked in the piece on CSS anchor positioning for Webflow tooltips.

When is :open the wrong choice for a marketing-site component?

:open is the wrong choice when the component is not a native HTML element with a defined open state. A custom dropdown, a tabbed interface, a sliding panel, or a custom popover anchored to a button is not one of the four native elements :open matches. For those components, the right tool is a different state mechanism, typically a class toggle driven by a Webflow Interaction or a small custom script.

The other case where :open is the wrong choice is when you need fine-grained state beyond open or closed. If your accordion has a third state, such as a loading state while content fetches, :open does not express that. The pattern in that case is to use the native open state for the open-or-closed axis and a separate data attribute for the loading axis. Style rules target both axes. This is the same kind of multi-axis state design that Chrome's scroll-driven animations work also points toward for animation-state authoring more generally.

If you are rebuilding accordions or modals on a Webflow site and want to talk through whether :open replaces an Interaction or whether the custom path still earns its place, drop me a line and tell me what the component does today. I will share the refactor pattern I am using at Phoenix Studio this quarter. Let's chat.