As part of the upcoming WordPress 7.1 release, we’re working on responsive styling – the ability to style blocks differently for tablet and mobile, directly from the editor. PR #75121 unifies the resizable editor with the device-preview switcher, which is the groundwork this feature builds on, and we’d love your help testing it.

More testing is needed to make sure it’s reliable and intuitive before it ships.

What is responsive styling?

Until now, a style you set on a blockBlock Block is the abstract term used to describe units of markup that, composed together, form the content or layout of a webpage using the WordPress editor. The idea combines concepts of what in the past may have achieved with shortcodes, custom HTML, and embed discovery into a single consistent API and user experience. – a font size, some spacing – applied the same way on every screen. Responsive styling lets you change a value just for tablet or just for mobile, without writing any custom CSSCSS CSS is an acronym for cascading style sheets. This is what controls the design or look and feel of a site..

A few real examples:

• A large heading on desktop that becomes smaller on mobile.
• Generous padding on desktop that tightens up on a phone.
• A different text color on the tablet than on the desktop.

To make these changes, first turn on Responsive editing from the device-preview dropdown – then switch the device view to Tablet or Mobile and edit the value while that view is active. The change is saved only for that breakpoint.

Why this matters

• Let’s you match a design across screen sizes without leaving the editor or hand-writing media queries.
• Keeps responsive tweaks, visual, and previewable – what you see is what visitors get.
• Moves WordPress toward fuller per-breakpoint design control in the editor.

How to test

The easiest way to test is WordPress Playground – no setup, nothing to install. This loads a fresh site with the latest GutenbergGutenberg The Gutenberg project is the new Editor Interface for WordPress. The editor improves the process and experience of creating new content, making writing rich content much simpler. It uses ‘blocks’ to add richness rather than shortcodes, custom HTML etc. https://wordpress.org/gutenberg/, which includes the responsive styling work plus any fixes that have landed since.

The link logs you in as admin and opens a fresh post, ready to test. Building the PR can take a minute on first load, so give it a moment.

Tip: The device view switcher is the Desktop / Tablet / Mobile dropdown in the editor’s top toolbar. Switching it is how you tell WordPress which breakpoint you’re looking at. With this PR, you can also drag the resize handles at the edge of the canvas to change the width.

Key changes to observe

• The device-preview dropdown and the resizable editor now work together: picking Tablet or Mobile sets the canvas width, and dragging the resize handles updates the device view to match.
• The dropdown has a new Responsive editing option. When it’s on, style changes you make apply to the current viewport (Tablet or Mobile) instead of Desktop.
• When Responsive editing is on, and you select a block on Tablet or Mobile, a viewport badge appears in the block inspector showing which device you’re editing. No badge is shown on the desktop, since edits there apply everywhere.
• Per-viewport edits are preserved and shown per device; turning Responsive editing off resets the editing state to default, and the badge disappears.

Test steps

You don’t need to follow all of these – pick what you have time for, and note anything that feels broken or confusing.

Scenario 1 – Resize handles and device view together (Post editor)

1. In the post editor, open the device dropdown and switch to Tablet (resize handles appear on the canvas edges).
2. Drag a handle inward and outward and watch the canvas width change.
3. Drag a handle all the way out to its widest – the handles should disappear, and you should land back in Desktop view.
4. Confirm the dropdown and the handles always agree on which view you’re in.

Note: In Desktop view, the handles may not show at first if there’s no spare space beside the canvas – use the dropdown to switch to Tablet/Mobile first. This is expected.

Scenario 2 – Pattern editor and Navigation editor

1. Edit or create a pattern (Appearance → Patterns, or via the site editor).
2. Here, the resize handles are always visible. Drag them and also use the device dropdown.
3. Confirm the two stay in sync and the canvas resizes smoothly.
4. Repeat the same check in the Navigation editor (Appearance → Editor → Navigation), where the handles are also always visible.

This change touches all four editors – Post, Template / Site (Appearance → Editor → Templates), Pattern, and Navigation – so testing across more than one is especially valuable.

Scenario 3 – Responsive editing (the main one)

1. Open the device-preview dropdown and turn on Responsive editing.
2. Select a block that has style options (e.g., a Heading). (On Desktop, no viewport badge is shown – this is intended.)
3. Switch the device preview to Tablet or Mobile – or drag the canvas to that width. A viewport badge now appears in the block inspector (right sidebarSidebar A sidebar in WordPress is referred to a widget-ready area used by WordPress themes to display information that is not a part of the main content. It is not always a vertical column on the side. It can be a horizontal rectangle below or above the content area, footer, header, or any where in the theme.) showing which device you’re editing.
4. Change a style (for example, a smaller font size). Confirm the change applies only to that viewport, not to Desktop.
5. Switch back to Desktop and confirm your per-viewport edit is preserved and the Desktop value is unchanged.
6. Turn Responsive editing off and confirm the editing state resets to default, and the badge disappears.

Also worth trying (quick real-world checks):

• Save and reload the editor – your per-viewport edits should still be there.
• Try it on a couple of different blocks (Group, Button, Image) and different properties (spacing, colors), not just font size.
• Set both Tablet and Mobile differently on the same block and confirm each is remembered.
• Undo/redo a per-viewport edit and confirm it behaves sensibly.

Scenario 4 – Hidden-on-device blocks respond to canvas resize

Block visibility itself has already shipped in Gutenberg. What’s new in this PR is that resizing the canvas (not just the device dropdown) now triggers it.

1. Add a paragraph and set it to be hidden on Tablet using the block’s visibility option.
2. Drag the resize handles into tablet width. The block should hide.
3. Drag back out to the desktop width. The block should reappear.
4. Confirm the device dropdown set to Tablet hides it too, exactly as before.

Always check the front end

After any responsive edit, verify it in both modes:

• Preview – use the editor’s Preview (the “View” / preview option) to open the page before publishing.
• Saved/published – Save, then open the live URLURL A specific web address of a website or web page on the Internet, such as a website’s URL www.wordpress.org.

In each mode, resize your browser from wide to narrow – or use your browser’s device/responsive view – through desktop, tablet, and mobile widths. Each width should show the style you set for it (e.g. the smaller font on mobile, the different color on tablet), and both Preview and the saved front end should match what you saw in the editor at the same width.

What to expect

This is active development, so expect a few rough edges, and the UIUI UI is an acronym for User Interface - the layout of the page the user interacts with. Think ‘how are they doing that’ and less about what they are doing. may still change. A couple of things that are known or by design:

• Resize handles in Desktop view (post/template editor): they may not appear at first because there isn’t enough space beside the canvas. Switch to Tablet or Mobile via the dropdown first. A follow-up is planned – see #71210.
• Responsive editing is desktop-first: a value you set on Desktop carries down to Tablet and Mobile unless you override it at that smaller viewport. So seeing the Desktop style on mobile (until you change it) is expected.
• Only styles set in the block inspector (right sidebar) – font size, colors, spacing, etc. – apply per viewport. Block toolbar controls like alignment apply to all devices.

For pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party. and theme developers

If your plugin or theme interacts with the editor canvas, please test it against this build – the underlying device/canvas model has changed:

• Code using getDeviceType() / setDeviceType() should keep working. getDeviceType() now derives the device from the canvas width, and setDeviceType() converts a device to a width.
• useResizeCanvas() is now deprecated and a no-op. If you rely on it, please tell us your use case.
• Responsive styles work out of the box for custom blocks that use block supports (color, typography, border, layout, dimensions), so custom block authors can test on their own blocks too (Note: if a block implements custom controls instead of block supports, responsive styles won’t apply to those).

Sharing your Feedback

There are a few ways to share what you find:

• General feedback / UXUX UX is an acronym for User Experience - the way the user uses the UI. Think ‘what they are doing’ and less about how they do it. impressions: comment on this post – it’s the best place for overall impressions and questions.
• Bugs and regressions: open a Gutenberg issue and reference PR #75121.
• Not sure whether it’s a bug? Ask in the #core-test channel on the WordPress SlackSlack Slack is a Collaborative Group Chat Platform https://slack.com/. The WordPress community has its own Slack Channel at https://make.wordpress.org/chat/.

We’d love to know, for example:

Specifics:

• Was it clear how to turn on Responsive editing and which viewport you were editing?
• Did the viewport badge correctly follow the device as you switched?
• Did a per-viewport style edit stay on that viewport only, and survive a save and reload?
• Did the device dropdown and the resize handles always agree on the current view?
• Did resizing feel smooth, or did handles get stuck or disappear unexpectedly?
• Did the editor preview match the front end at each width?
• Did anything feel slower, confusing, or broken?

The bigger picture:

• How intuitive did responsive styling feel overall – were you able to do what you wanted without guidance?
• Does this solve a real problem for you? Would you use it in an actual project?
• Anything about the overall approach that felt right, or that you’d design differently?

When reporting something, a short step-by-step with a screenshot or screen recording helps a lot. To make a report actionable, please include:

• The editor you used (Post, Template / Site, Pattern, or Navigation).
• Your browser and OS, and whether it was a touch device.
• The Gutenberg / WordPress version or PR build.
• The active theme – especially block themes with custom breakpoints.

Props to @huzaifaalmesbah, @jeffpaul, @talldanwp, @isabel_brison, and @annezazu for review and feedback on this post.

#7-1, #call-for-testing, #core-test, #full-site-editing, #gutenberg