Integrate Resizable Editor with Device Preview and add Responsive editing

[t-hamano]

• Attempts to fix Allow access to responsive canvas resizing beyond just for template parts #71210
• Related to Add block visibility breakpoints support for dynamic configuration #73735

Note

This PR originally aimed to integrate Device Preview with the Resizable Editor. However, following discussion, its scope shifted to relocating the Responsive editing UI.

What?

This PR does two things:

1. Integration — Unifies device view and the resizable editor, which are currently mutually exclusive. In the post and template editors, you could only set the three specific device widths and nothing in between. Meanwhile, in the pattern and navigation editors, you could resize freely but could not fit the canvas to a specific device width.
2. Relocating the Responsive editing UI — Moves the Responsive editing entry point into the device preview dropdown. Along with this, the responsive (viewport) style state becomes global rather than per-block: switching the device preview (or resizing the canvas) drives which viewport the block style edits in the inspector apply to.

How?

The core idea is to treat the canvas width (in pixels) as the single source of truth, instead of a discrete device type. The device preview dropdown becomes just a tool to set a specific canvas width, and resizing the canvas is the same operation expressed differently.

New private APIs

• getCanvasWidth() / setCanvasWidth( width ) (core/editor) — Gets/sets the canvas width in pixels. While Responsive editing is enabled, setting it also drives the viewport state.
• isResponsiveEditing() / setResponsiveEditing( enabled ) (core/block-editor) — Gets/toggles whether Responsive editing is enabled (session-only). Lives in the block-editor store because it is an implicit part of the block style state system.
• getStyleStateViewport() / setStyleStateViewport( viewport ) (core/block-editor) — Gets/sets the globally selected viewport state. Block style edits in the inspector apply to this viewport. The viewport is tracked globally, separate from the per-block style state.

Changed / deprecated APIs

• getDeviceType() / setDeviceType() (core/editor) — getDeviceType now derives the device type from canvasWidth instead of a stored deviceType (and returns Desktop while zoomed out), and setDeviceType converts the device type to a width and dispatches setCanvasWidth rather than storing the device type directly.
• useResizeCanvas() — Deprecated and turned into a no-op. This hook only existed for the old device view, which canvas width now replaces.
• updateDeviceTypeForViewportState() (private) — Removed. The viewport ↔ device-preview sync now lives inside setCanvasWidth.
• getSelectedBlockStyleState() (private) — The viewport in the returned state now comes from the global viewport state (getStyleStateViewport()) instead of the per-block stored value; the per-block pseudo state is unchanged.

Testing Instructions

Post Editor, Template Editor

• Please note that the resize handles will not be visible initially when the canvas width corresponds to the Desktop view. This is because there is not enough space on the left or right side of the canvas for them to appear. This may be addressed in a follow-up PR. See Allow access to responsive canvas resizing beyond just for template parts #71210 (comment). In the post editor and template editor, you will need to use the device preview dropdown first.
• In mobile or tablet width, expand the resize handles to their fullest extent. The resize handles should disappear and you should switch to desktop view.

4dd92e2f8dde1b20e416c7c63516bf3e.mp4

Pattern Editor

The resize handles are always visible in this editor. Make sure the device preview dropdown and canvas width work together nicely.

7f71a97bacedc7e0526cc396311b7b28.mp4

Responsive editing UI

• Open the device preview dropdown and enable Responsive editing.
• Select a block that supports styles. A viewport badge should appear in the block inspector.
• Switch the device preview to Tablet or Mobile (or resize the canvas to the corresponding width). The viewport badge should follow the current device.
• Change a style and confirm the edit applies only to the selected viewport, not to Desktop.
• Switch back to Desktop and confirm the per-viewport edits are preserved and shown per device.
• Disable Responsive editing and confirm the viewport editing state resets to default and the badge disappears.

[github-actions]

Size Change: +96 B (0%)

Total Size: 7.51 MB

📦 View Changed

Filename	Size	Change
build/scripts/block-editor/index.min.js	383 kB	-106 B (-0.03%)
build/scripts/edit-post/index.min.js	53.3 kB	-17 B (-0.03%)
build/scripts/editor/index.min.js	475 kB	-54 B (-0.01%)
build/styles/editor/style-rtl.css	30.8 kB	+67 B (+0.22%)
build/styles/editor/style-rtl.min.css	26.2 kB	+62 B (+0.24%)
build/styles/editor/style.css	30.9 kB	+80 B (+0.26%)
build/styles/editor/style.min.css	26.2 kB	+64 B (+0.24%)

_{compressed-size-action}

[t-hamano]

The only exception is StyleBook, where the device preview dropdown is not available, and the canvas is not resizable. I plan to remove this limitation in a follow-up.

[github-actions]

The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the props-bot label.

If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message.

Co-authored-by: t-hamano <wildworks@git.wordpress.org>
Co-authored-by: Mamaduka <mamaduka@git.wordpress.org>
Co-authored-by: youknowriad <youknowriad@git.wordpress.org>
Co-authored-by: ramonjd <ramonopoly@git.wordpress.org>
Co-authored-by: jasmussen <joen@git.wordpress.org>
Co-authored-by: tellthemachines <isabel_brison@git.wordpress.org>
Co-authored-by: talldan <talldanwp@git.wordpress.org>
Co-authored-by: nikunj8866 <nikunj8866@git.wordpress.org>
Co-authored-by: stokesman <presstoke@git.wordpress.org>
Co-authored-by: jameskoster <jameskoster@git.wordpress.org>
Co-authored-by: fcoveram <fcoveram@git.wordpress.org>

To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook.

[Mamaduka]

I haven't tested this thoroughly, but I've left some notes based on the initial review.

I think it's an interesting approach. Can you elaborate a bit on why a new global state is needed rather than just using the previous method?

[t-hamano]

@Mamaduka Thanks for the review!

Can you elaborate a bit on why a new global state is needed rather than just using the previous method?

The reason I introduced the new canvasWidth state is because getDeviceType and setDeviceType are public APIs. I know several plugins depend on them, and those APIs need to continue to be available in the same way as before.

[Mamaduka]

Yes, but what prevents us from using useResizeCanvas and the old system, but only enabling resizing when deviceType !== 'Desktop' and probably some other conditions depending on the post type.

I'm not saying that either option is better; I'm primarily curious about the technical decisions.

[tellthemachines]

In resizable editors, getDeviceType always returns Desktop, so the block hiding feature does not work in resizable editors, such as the Pattern Editor and Navigation Editor.

Can you give me some steps to repro this? A quick check of the pattern editor by creating a new pattern, adding a block and selecting "hide on desktop" hides it successfully for me:

We're not only checking the device type but also the viewport size for the block hiding logic, so if it doesn't work in responsive editing there's something wrong with it 😅

[t-hamano]

In resizable editors, getDeviceType always returns Desktop, so the block hiding feature does not work in resizable editors, such as the Pattern Editor and Navigation Editor.

Can you give me some steps to repro this?

@tellthemachines Can you try the following steps? I tested it on trunk (f2c4004).

1. Appearance > Editor > Patterns
2. Create a new pattern
3. Enter some text into the default Paragraph block.
4. Open the Hide block modal and check "Hide on Tablet”.
5. Change the editor width slightly. The block will always be visible.

d0d26373639acd414cd859e8ce4e469a.mp4

[t-hamano]

Yes, but what prevents us from using useResizeCanvas and the old system, but only enabling resizing when deviceType !== 'Desktop' and probably some other conditions depending on the post type.

@Mamaduka Can you elaborate a bit more on your concerns? I may not be understanding you properly 😅

[talldan]

Thanks for working on this Aki! How it was working before was definitely confusing me so great to have a better solution in.

[youknowriad]

The "responsive editing" toggle says: "Edits apply only to the current state". For me there are two things that are ambiguous here.

• "Edits": which edits? I added / removed blocks and they applied to all states. So should this say "Style edits" or something like that.
• "current state": Should this say "current viewport". State can mean other things

This is definitely an improvement though 👍

[youknowriad]

The other confusing thing is that I had a custom mobile style for a block, and I was on "mobile viewport", if I disable "responsive editing" the style is gone (not talking about the sidebar, but from the preview)? I feel like the preview/rendering of viewports shouldn't depend on the "responsive editing" toggle, it should always render the current viewport's styles.

[t-hamano]

The other confusing thing is that I had a custom mobile style for a block, and I was on "mobile viewport", if I disable "responsive editing" the style is gone (not talking about the sidebar, but from the preview)? I feel like the preview/rendering of viewports shouldn't depend on the "responsive editing" toggle, it should always render the current viewport's styles.

Responsive styles should always be applied appropriately according to the current canvas width 🤔

responsive-style.mp4

[Mamaduka]

I've been playing with the feature for the local meetup demo, and it's working well. Can confirm that responsive styles are remaining in preview after disabling "responsive editing".

I've also noticed that alignments can't be set as device-specific, e.g., Group/Image might take up full width on smaller screens. It took me a moment to realize that these controls are still universal and don't account for devices.

I don't know what the plan is here, but it might be better to hide them until they're working.

[youknowriad]

Responsive styles should always be applied appropriately according to the current canvas width 🤔

This didn't work for me for sure, so maybe there's some flow to break it. I'll try to reproduce it at some point, I was also playing with hover styles at that point.

[talldan]

I've also noticed that when Responsive Editing is active and Desktop is selected, a badge is being shown:

I think that's potentially confusing because changes on desktop apply to all breakpoints/viewports.

I'll work on a PR (edit: PR is #79615) to revise a couple of the aspects mentioned.

[RubenMartins]

As a matter of fine tuning could this manual resize preview include a ruler or indication of the width selected like 1437px or something else to test specifically in a certain dimension like a lot of computers at 1366px/1536px is always a struggle cause is not tablet or desktop but something in between very often causing issues.

[ramonjd]

Maybe an alternative could be a w x h badge, similar to what Chrome shows top right when the console is open?

[mikemcalister]

@t-hamano Where would be the best place to provide feedback on this responsive editing feature at this point?

[ramonjd]

Where would be the best place to provide feedback on this responsive editing feature at this point?

@mikemcalister I'll pre-empt, but saying, if you are able, it'd be helpful to have Github issues to describe any enhancements or fixes related to your testing, and then reference this PR.

If it's on responsive editing of styles in general, this is the 7.1 iteration issue: #77817

Edit: or here: https://make.wordpress.org/test/2026/07/03/call-for-testing-responsive-styling/

Thank you!