[WIP] Unify device switcher and resizer in overlay editors#75485
Closed
[WIP] Unify device switcher and resizer in overlay editors#75485
Conversation
Enables device preview dropdown (Desktop/Tablet/Mobile) to work alongside resize handles in navigation, template-part, and pattern editors - similar to Chrome DevTools. - Centralize device preview widths in shared constants - Make ResizableEditor respond to deviceType changes - Pass deviceType to ResizableEditor and conditionally skip useResizeCanvas - Enable device dropdown for all post types except attachments The device presets and drag handles now control the same dimension, allowing users to snap to presets or resize freely.
When users manually resize using drag handles, the device dropdown now switches to "Custom" instead of staying on a preset. This follows the Chrome DevTools pattern and clearly indicates free-resize mode. - Add Custom to DEVICE_PREVIEW_WIDTHS/HEIGHTS constants - ResizableEditor detects when resize doesn't match presets (±5px) - Automatically switches to Custom when manually resized - PreviewDropdown shows Custom option with dragHandle icon - Users can manually select Custom or switch back to presets
Bug 1: Custom option now only appears when resizing is enabled - Calculate enableResizing in Header component - Pass enableResizing prop to PreviewDropdown - Filter choices to exclude Custom when resizing disabled Bug 2: Restore smooth animation between device presets - Add is-animating class with CSS transition - Animate only when switching between known presets - Disable animation during manual drag for smooth UX - Track previous device type to determine when to animate - Clean up setTimeout on unmount
github-actions
bot
added
[Package] Editor
getdave
added
[Type] Enhancement
|
Size Change: +619 B (+0.02%) Total Size: 3.03 MB
ℹ️ View Unchanged
|
Contributor
|
This makes sense to me, and I think it aligns with more modern views of dealing with breakpoints. I think your demo video has broken heights, but overall it seems like a much better experience than what we have. |
Contributor
|
What do you think of adding input controls on the template part tab specifically for overlays for users to manually control width and height? Obviously out of the scope of this exploration, but I think it would make sense to have in this particular context. |
Contributor
|
Although it doesn't seem to be working for me, I like the direction. It seems like the reason we disabled this previous was a technical constraint, so it seems good to resolve this and deliver a better UX. |
Contributor
Author
|
Great. Thanks for feedback. What we need here
In all honesty I'm targeting WordPress 7.1 with this. I can't see this landing in time for WordPress 7.0. |
Contributor
|
Not sure if I'm seeing the latest changes correctly. Sorry in advance, sometimes I can't run PRs correctly. Nonetheless, here is what I see. template.part.breakpoint.review.mp4I'm not convinced about the overall experience. The breakpoints for Desktop, Tablet and Mobile are more commonly displayed as a range of widths (values between a min- and max-width final point) rather than a static one. Without this range, users will see most of the time the "custom" set. In the range logic, I would expect to move the handlers to expand or shrink the viewport and reflect lively the corresponding device in the icon button. Chrome makes that range visually more explicit. chrome.reponsive.breakpoints.mp4On the other hand, and seemingly out of this PR's scope, the custom is a cryptic setting and doesn't provide enough information about what value is behind. Based on how other products address breakpoints, the customization is about adding/removing/set to default the breakpoints. That said, I would expect the customization option to trigger a flow where breakpoints are listed and the user can add/remove these and go back to the default. |
Contributor
|
Is this PR fixing the same issue as #75121 is? If yes, there's some important conversation there to consider. It's not blocking, just relevant, and worth consolidating these two. |
Contributor
Author
|
Yes I've just been made aware of #75121. I was thinking surely someone has looked to fix this already. I'll close this one in favour. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
5 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What?
Enables the device preview dropdown (Desktop/Tablet/Mobile) to work alongside resize handles in navigation, template-part, and pattern editors - similar to Chrome DevTools' unified approach.
Why?
The device switcher and resize handles were previously mutually exclusive. PR #65970 disabled the device dropdown in these editors to avoid conflicts, but users need both:
Related to #75222, this provides the foundation for viewport-aware overlay editing by making device switching available in template part contexts.
How?
Unified dimension control: Device presets and drag handles now control the same
ResizableEditorwidth:DEVICE_PREVIEW_WIDTHS)ResizableEditorresponds todeviceTypechanges, snapping to preset widthsuseResizeCanvasis bypassed (Desktop mode), lettingResizableEditorhandle widthCustom mode: Manual resizing switches to "Custom" in the dropdown (like Chrome DevTools' "Responsive" mode), clearly indicating free-resize state. Switching back to a preset snaps to that width with smooth animation.
Testing Instructions
Screenshots or screencast
Screen.Capture.on.2026-02-12.at.17-11-09.mp4