What Are CSS Name-Only Container Queries in Chrome 148?

Chrome 148 shipped on May 5, 2026 with a small CSS change that meaningfully improves how I write component CSS for Webflow sites. Name-only container queries now work. You can write @container --my-container in a stylesheet without declaring container-type on the parent. Chrome 148 also adds the at-rule function inside @supports for cleaner feature detection, and the revert-rule keyword for design-system cascade work. None of these features are individually large, but together they tighten the custom-code patterns Phoenix Studio uses on most B2B SaaS Webflow projects. In this piece I walk through what changed, why the old pattern required container-type, where Safari and Firefox stand, and the exact refactor I am running on a current client component library this week.

What changed in CSS container queries in Chrome 148?

Chrome 148, released May 5, 2026, removed the requirement to declare container-type on a parent element when querying a CSS container by container-name. The @container rule now matches a named container without the type declaration, simplifying the markup and styling needed to make container queries work on real components. Chrome 148 also added the at-rule function inside @supports and the revert-rule keyword.

The complete release detail is in the Chrome 148 release notes. The CSS Containment Level 3 spec at the CSS Working Group covers the broader container query feature. For Webflow designers writing custom code, the change makes the @container rule usable with one CSS declaration on the parent rather than two. Small change, real friction reduction across an entire component library.

Why did container queries previously require a container-type?

Container queries previously required a container-type declaration because the original spec needed the browser to know in advance which elements should be treated as query containers to avoid performance regressions. The container-type property was the explicit opt-in. Chrome 148 ships an updated implementation that uses container-name as a sufficient opt-in signal, removing the duplicate declaration.

The original constraint was reasonable when container queries were new and the performance implications were not fully understood. After three years of production use, the Chrome team determined that container-name alone provides enough information for the browser to do the right work without performance regression. The result is cleaner CSS authoring. Webflow Designer-produced markup that already has class hooks for components benefits the most, because the existing class can become the container-name without restructuring the HTML.

How does name-only @container actually work in a Webflow project?

In a Webflow project, name-only @container works by giving a component div block a container-name in custom code, then writing @container --component-name rules in a stylesheet or embed. The browser treats the named element as a query container automatically, without a separate container-type declaration. The rest of the component's CSS is written normally inside the @container block.

The Designer-side workflow looks like this in practice. Build the component visually in the Designer as you normally would. Identify the component's outermost wrapper div. Add a custom code embed near the component or in Page Settings that sets container-name on that wrapper using a CSS rule keyed to the Designer-set class. Write the @container rules that respond to the wrapper's inline size. The component now adapts to its container's width regardless of where it appears in the page layout, which is the core benefit of container queries over media queries for component-driven sites.

What is the new at-rule() function inside @supports?

The at-rule function inside @supports lets CSS feature-detect at-rules like @container or @starting-style by name. Write @supports at-rule(@container) and a CSS block that runs only when the browser supports container queries. Before Chrome 148, feature-detecting at-rules required testing a specific property the at-rule used, which was indirect and brittle.

For design systems, the at-rule function matters because it lets the cascade gracefully provide a different style path on browsers that lack a specific at-rule support. The pattern is: write the modern container-query-driven layout inside an @supports at-rule block, and write the fallback media-query-driven layout outside it. Both paths coexist cleanly. Webflow custom code in the head section can carry both paths without conflict. The browser picks the right one based on actual feature support, not on user agent detection.

Why does the revert-rule keyword matter for design systems?

The revert-rule keyword resets a CSS property's value to the value defined in a previous rule, not to the property's initial or inherited value. This matters for design systems because it lets a specific override revert just the parts of an upstream rule it needs to undo, without resetting unrelated properties. It is a finer-grained cascade control than the existing revert keyword.

For Webflow custom code that layers on top of Designer-generated styles, revert-rule is the difference between resetting one property cleanly and rewriting a full rule block. The pattern that benefits most is component overrides in specific page contexts. If the global component sets padding, border, and background, and a page-specific context needs only the padding reverted, revert-rule does that without touching the border and background. The Designer-side workflow does not change, but the custom code on top of it gets meaningfully shorter.

Where do Safari and Firefox stand on these features?

Safari has shipped container queries broadly and is tracking the name-only support change. Firefox supports container queries but has not yet flagged name-only support for a specific upcoming release. The at-rule function in @supports and the revert-rule keyword are Chrome-first features as of May 2026, with cross-browser implementations underway but not stable.

The practical implication is that name-only @container works in Chrome today and falls back gracefully in Safari and Firefox by failing to match. Writing the same rule with an explicit container-type as the fallback is the cross-browser pattern. Safari and Firefox readers see the rule match because they read both selectors. Chrome readers see it match through either path. The at-rule function and revert-rule are Chrome-only for now, so use them only inside @supports blocks that provide a fallback for non-supporting browsers.

Should you use name-only container queries on a production marketing site?

Yes, but with the explicit-container-type fallback alongside it. Write the @container rule once with container-name as the selector and add container-type on the parent in a separate rule. Browsers that support name-only behavior use it. Browsers that require container-type read both rules and get the same result. The fallback pattern is one extra line of CSS per container.

For Phoenix Studio projects, the pattern I am moving toward is to maintain both the name-only and the type-plus-name patterns side by side until the next major Safari and Firefox release confirms cross-browser parity. The cost of carrying the fallback is small. The cost of skipping it is a broken layout for a non-trivial slice of visitors. The same cost-benefit pattern shows up in component-scoped Interactions, where the right answer is usually to ship the modern path and the fallback together rather than picking one.

How do you wire this into Webflow custom code today?

Wire name-only container queries into Webflow by adding two pieces of custom code. The first piece sets container-name on the component wrapper using its Designer class. The second piece writes the @container rules that drive the component's responsive layout. Place both pieces in Page Settings custom code or in a site-wide global custom code block.

The Designer-side pattern is to keep the visual component build unchanged and to add CSS in the Before Head Tag section of the page. The custom code block contains the container-name declaration keyed to the Designer class, the optional container-type declaration as the cross-browser fallback, and the @container rules that drive the component layout. The visual component in the Designer continues to look the same. The responsive behavior at runtime now reads the container's width rather than the viewport's width, which is the right semantics for component-driven design.

Does this change Webflow's recommended component patterns?

It does not change Webflow's recommended component patterns directly, but it reduces the custom code needed to make components respond to their context rather than the viewport. The Designer's built-in responsive breakpoints still cover the page-level layout. Container queries handle the component-level adaptation that media queries cannot express cleanly.

For component libraries like the ones I have built for several B2B SaaS clients, the practical pattern is to use Webflow's native breakpoints for page layout and to use container queries for the components that appear at multiple widths across the site. A pricing card that lives in a three-column grid on the pricing page and in a single column in the footer needs to look different in those two contexts. Container queries express that without duplicate variants. The same pattern shows up in CSS subgrid for editorial article layouts, where the container's measurement, not the viewport's, drives the right visual.

When will this feature be cross-browser Baseline?

Name-only container queries will likely reach cross-browser Baseline within the next twelve to eighteen months, once Safari and Firefox ship matching implementations and the feature has been stable across browsers for the Baseline waiting period. The at-rule function and revert-rule keyword are likely on similar timelines but slightly further out.

For projects scoped over the next year, treat name-only container queries as a progressive enhancement that compounds slowly. The fallback pattern works today, and the modern path takes over automatically as readers update their browsers. The compounding savings are real but small per project. Across a large Webflow practice with many active sites, the total reduction in custom code volume is meaningful at the quarterly level, which is the right scale to think about it on. The bigger lift is the next CSS feature that lands a few months from now, and the next, each one tightening the component library further. As I noted in asymmetric grid patterns that benefit from container queries, the modern CSS surface is what is making Webflow components reach further with less code.

If you are running a Webflow component library and want to talk through which of these Chrome 148 features earn a place in your custom-code stack this quarter, drop me a line and tell me what your current container-query pattern looks like. I will share the exact refactor I am running on the Phoenix Studio component library this week. Let's chat.