Responsive Styling Lands in Gutenberg 23.5 for WordPress 7.1

Every agency I know has, at some point, wired up a custom class or a bespoke CSS variable just to change one padding value on tablet. It works. It always works. And every time someone touches the design six months later, they discover the class in a place nobody wrote down, break a layout, and blame the theme.

WordPress is finally about to close that gap in a first-class way. Not as a plugin, not as a theme trick — as an editor feature. The block editor is getting per-viewport styles you can set from the toolbar, and the machinery landed in Gutenberg 23.5 last week. If it survives the WordPress 7.1 cycle intact, the next generation of block themes will not need a media-query cheat sheet to look right on phones.

I want this to be good. I have also watched enough “responsive controls” features come and go across the last two decades that I want to see it in the wild before I bet a client site on it. Here is what actually shipped, what the testing call is really asking for, and what I would and would not do about it this week.

What is actually new

On July 3, Nikunj Hatkar from the WordPress Test team opened a public call for testing on responsive styling for WordPress 7.1. The feature ships inside Gutenberg 23.5, which was released on July 1, 2026, and it merges two things that used to be separate: the device preview dropdown (Desktop / Tablet / Mobile) and the resizable editor canvas.

The core plumbing is pull request #75121 by t-hamano, merged June 26 after fifty commits of iteration. It treats “canvas width in pixels” as the single source of truth instead of three discrete device buckets, moves the responsive editing toggle inside the device dropdown, and makes viewport style state global — driven by which device or width you selected, not stored per block. New private APIs on the editor and block-editor stores (getCanvasWidth, isResponsiveEditing, getStyleStateViewport) expose the mechanism to core; the older getDeviceType public API stays put for backwards compatibility.

The workflow the testing call describes is simple, and that is the point. Toggle responsive editing on, switch to Tablet in the dropdown, change a font size or a padding value, save, view the front end on a tablet-width viewport, and see the change apply there and only there. The 7.1 roadmap phrases it plainly: “this work lets you apply responsive styles, like a font size at a certain viewport, directly in the editor without writing custom CSS.” It hits both Global Styles and individual block instances, and it sits on the same style-states mechanism that already powers the hover, focus, and active pseudo-state work in the same release.

Testers are asked to try it in the Playground build linked from the announcement (no local install required), poke the resize handles and the device dropdown, verify Pattern and Navigation editor compatibility, and confirm that per-viewport edits apply on the front end in both preview and published modes. Bugs go to the Gutenberg repo referencing PR #75121; general feedback stays on the announcement post; anything hazy goes to #core-test on Slack. The window is short: WordPress 7.1 Beta 1 pins trunk on July 15 and the general release is August 19, 2026.

Why it matters for WordPress and WooCommerce people

For agency teams, this is the piece the block editor has been missing since the site editor arrived. Every real client project I have shipped in the last three years has needed at least one of: a hero heading that shrinks below a certain width, a product grid that switches from four columns to two on tablet, or a call-to-action button that changes padding on mobile because the text wraps. All of those have been possible — through theme.json, through additional CSS, through custom blocks, through classes bolted onto group blocks. None of them have been possible for the content editor to do without help. That last part is what changes.

For WooCommerce stores specifically, the impact is concrete. The Cart, Checkout, and Product Collection blocks all rely on responsive layouts that today either come from the store’s block theme or from a designer writing CSS against WooCommerce class names. If a merchant can open the Product Collection block, switch to Mobile, and change the column count and image size for phones without touching a stylesheet, the number of “please make it look right on iPhone” tickets that require a developer drops sharply. That is real hours back for teams running fifty stores.

The bigger picture is where I get careful. The 7.1 cycle is dense: responsive styling, pseudo-state styling, three new blocks (Playlist, Table of Contents, Tabs), AI Client streaming, Connectors auth expansion, Notes upgrades, and React 19 back behind an experiment flag. Each of those touches the same editor surface. Responsive styling is the one users will see first, and it is also the one where a regression will feel like the whole editor is broken. That is precisely why the testing call is unusually specific about scenarios instead of “please try it.”

What I would do (or not do) about it

This week: install the Gutenberg 23.5 plugin on a staging site or open the Playground link from the testing call, and spend twenty minutes trying to break the workflow. Not to file a philosophical bug — to answer, honestly, whether it can replace the CSS you currently write for a specific client. Pick a page with a hero, a product grid, and a footer, resize the canvas, change one value per viewport, and check the rendered page across three real widths. Report what breaks. The testing team wants scenario reports, not opinions, and this is the two-week window where those reports still change the shape of the feature before Beta 1.

What I would not do this week: ship it to a production client site, even under a feature flag, even on a sub-page. The internal APIs are marked private for a reason, block visibility during canvas resize is one of the four flagged risk areas, and any bug that lands in the last week before Beta 1 will still ship into 7.1. Staging is the right surface until at least RC 1 on August 5.

What I would start planning now: which pieces of your theme’s current responsive CSS become redundant if this ships as advertised. Every layout override tied to a viewport breakpoint that was previously custom code is a candidate for deletion when 7.1 lands. That is the kind of debt cleanup that is easy to defer and easy to regret — a theme with fewer overrides is a theme that survives the next core update without hand-holding.

WordPress has always won the long game by making the boring things reliable — redirects, revisions, capabilities, plugins that keep working across releases. Responsive styling in the editor, if it lands cleanly, is one more piece of that pattern. Worth testing this week. Worth trusting in production after RC 2.