WordPress 7.1 Responsive Block Styles Land in Global Styles

For as long as I have been shipping WordPress themes — and that goes back to when the theme was three PHP files and a stylesheet in a folder — the responsive story lived in one place: a block of media queries at the bottom of style.css. Everything else moved forward. Colours became presets. Spacing became tokens. Typography became a scale in theme.json. Media queries stayed exactly where they were in 2012, in a stylesheet outside the design system, drifting a little further from the rest of the theme every release.

WordPress 7.1 is the release that finally moves them inside. Tablet and mobile styles are now part of Global Styles and part of each block’s own style attribute — same shape as the rest of the design system, same theme.json file, same governance layer that gets you a WordPress site upgrading cleanly ten years later.

I have been waiting for this since the block editor shipped. Here is what actually landed, and where I would spend my Wednesday afternoon before the August 19 GA.

What is actually new

Isabel Brison published the dev note “Responsive Block Styles and Configurable Viewports in WordPress 7.1” on Make/Core on August 5, 2026, the same day 7.1 Release Candidate 1 shipped. Reviewer @tyxla, contributors @ramonopoly and @wildworks. The change is tracked under Trac #65164 (responsive style states) and Trac #65596 (customisable breakpoints).

The mechanism is two new keys — @mobile and @tablet — that you can nest anywhere a block style already lives: inside styles.blocks.core/paragraph in theme.json, inside a block instance’s style attribute, inside a block style variation. They apply to every block support the design system already speaks: typography, colour, background, border, dimensions, spacing, and layout. The default style stays the base; the responsive keys override it inside their viewport range. Brison’s own line is worth pinning: “The default style remains the base style and applies at every viewport. Tablet and Mobile styles override that base within their respective breakpoint ranges.”

Default breakpoints ship as @media (width <= 480px) for mobile and @media (480px < width <= 782px) for tablet. Desktop is the base — there is deliberately no @desktop key. And crucially, both breakpoints are configurable at the theme level:

"settings": {
  "viewport": {
    "mobile": "30rem",
    "tablet": "45rem"
  }
}

Values must be non-negative numeric lengths in px, em, or rem. Percentages, CSS functions, and unitless numbers are rejected. If a theme sets tablet less than or equal to mobile the tablet breakpoint is dropped rather than allowed to invert. settings.viewport is top-level only; it is not per-block-type by design.

Per-instance responsive styles live inside the block’s existing style attribute — no new attribute, no data migration:

<!-- wp:paragraph {"style":{"@mobile":{"typography":{"fontSize":"1rem"}}}} -->

Core generates media-query-scoped CSS on render and adds stable classes to the rendered block. Per-instance declarations get !important so they beat the base inline style. There is an editor opt-out — the responsiveEditingEnabled setting defaults to true; flip it off and the “Responsive styles” toggle and “Viewport” group disappear from the States dropdown while device previews stay untouched.

Two related dev notes shipped the same day and are part of the same picture. Daniel Richards’ “Pseudo and Custom Style States” adds :hover, :focus, :focus-visible, and :active to Button and Navigation Link, plus a -current custom state on Navigation Link for the active menu item. Pseudo states nest inside responsive states — @mobile then :hover — so the two APIs compose. Aaron Jorbin’s RC phase note and Milana Cap’s 7.1 Field Guide (310+ Trac tickets summarised) pin the surface for GA on August 19.

Backwards compatibility is total. If a theme never touches the new keys, nothing changes. Existing block markup renders identically. Old theme.json files stay valid.

Why it matters for WordPress and WooCommerce people

Every WooCommerce store I have shipped in the last five years has the same pattern in its child theme: a set of clean, tokenised styles for the product grid, hero banners, cart layout, and account pages — followed by twenty or thirty lines of @media (max-width: 768px) overrides at the bottom of the stylesheet fixing font sizes on the phone. That bottom section is where design-system discipline goes to die. It is unversioned in any meaningful sense, invisible to theme.json tooling, and the first place theme-migration budgets balloon when a client wants to move to a new design.

Moving those overrides into theme.json under styles.blocks.core/group.@mobile or styles.blocks.core/heading.@tablet puts them exactly where the rest of the design system lives. The tokens travel with the theme file. They are discoverable to wp theme.json tooling. They land in the same code review as the base styles. And when a store swaps themes in eighteen months, the responsive story travels intact instead of being reverse-engineered from a stylesheet nobody read.

Configurable viewports matter more than they look. Every serious agency has a design system that already defined its own breakpoints — 40rem and 60rem, or 640px and 1024px, or whatever the brand book locked in three years ago. Being able to declare those under settings.viewport and have every responsive style resolve against them means the theme finally speaks the client’s language natively instead of coercing everything into WordPress’s defaults.

The pseudo-state note lands in the same window and I would treat them as one release. Button hover states are the single most-requested “small tweak” I get on WooCommerce project handovers. Until now the answer was a Additional CSS snippet. Now it is one block in theme.json.

What I would do (or not do) about it

Four things this week, on staging clones running RC1 — not on production, and not on any WooCommerce 11.0 site whose upgrade window is still open from Monday.

First, grep every child theme and every Additional CSS blob you manage for @media declarations. That list is the migration inventory. Most of it collapses cleanly into @mobile and @tablet keys under the corresponding block in theme.json. Do not migrate anything on GA day — list now, migrate in the September window after 7.1.1 clears.

Second, on one representative site, add settings.viewport to theme.json with the breakpoints your design system already uses. If your brand book says 640px and 1024px, declare that, then port two or three of the most-hit responsive overrides — a heading size, a paragraph size, a group padding — and diff the rendered HTML and generated CSS against the existing production behaviour. Empty diff before you touch anything else.

Third, for stores where the shop manager or brand team edits pages directly, decide whether responsiveEditingEnabled stays on. My default is on — the “Responsive styles” toggle is the same shape as every other block inspector control and editors figure it out — but on stores where the content team is small and the design is locked, flipping it off in a mu-plugin keeps the surface tight and removes a source of “why does the mobile look different from what I designed” tickets.

Fourth, do not install any plugin whose entire pitch is “adds a UI for responsive block styles”. The surface is one JSON structure and one settings key. Wrapping it in a settings screen that stores breakpoints in wp_options is exactly the technical debt this API was designed to retire — the breakpoints belong in the theme file, versioned with the rest of the design tokens, not in a database row that survives one theme migration and vanishes on the second.

Two calendar notes. WooCommerce 11.0 landed Tuesday per Brian Coords’ release post; the Action Scheduler 4.0 dependency is still the change to triage most carefully. Keep WooCommerce 11.0 and WordPress 7.1 in separate change windows. Two moving surfaces on the same estate on the same afternoon is how you spend Saturday narrowing which one broke.

Every design token that leaves the “random CSS” folder and moves into theme.json makes the next theme migration cheaper by a percentage point. Responsive styles are the biggest single bucket of them still outside the system. WordPress 7.1 finally brings them in — quietly, additively, and without breaking anything that shipped before.