Repository navigation
Responsive styles: design feedback on viewport popover #80252
Description
The following is feedback for the new responsive viewport selector in the top toolbar.
Usually when there is a repeated text element in the copy, there is an opportunity to be less redundant. For example, "style, style, style" "edit, edit, edit" "preview, preview, preview" are all the repeated bits in the current design. What I think might solve this problem is to not have a text label for each viewport option and instead have a single explanation where it matters; the toggle control.
Here is a sketch, please ignore the Claude styling.
| Before | After |
|---|---|
 |
 |
- Responsive styles control: this should be a toggle. I’m turning on this mode, not just selecting it from a list. Something that says, "this preview toggle is now turning into a new mode".
- Verbose repeated text is not a problem anymore. In this new design, you don't need to change the help text for each of the viewport options (desktop, tablet, mobile).
- A dot indicates that there are changes.
- Optionally, you could change the toggle help text based on what viewport you have selected.
Edit: I think yes, you'd want to change the toggle help text for Desktop to something like, "Style edits will affect all viewport sizes"
Originally posted by @davewhitley in #80146 (comment)
Activity
andrewserong commentedon Jul 14, 2026
Good points, and thanks for opening an issue to discuss this! A few questions come to mind (I'm not a designer by the way, but this dropdown is quite a key one in the editor so I think we need to be pretty careful in how we approach changes to it):
theme.json?davewhitley commentedon Jul 15, 2026
Thanks for taking a look!
andrewserong commentedon Jul 16, 2026
For injection, it's a feature that's been around since WP 6.7 (here's where it was announced: https://make.wordpress.org/core/2024/10/18/extending-the-preview-dropdown-menu-in-wordpress-6-7/)
There's some documentation on how to use it here: https://developer.wordpress.org/news/2026/02/how-to-add-custom-entries-to-the-editor-preview-dropdown/
And as an example, from a quick test on WordPress.com they inject an "Email preview" menu item:
For our purposes here, we need to assume that the preview dropdown will include an unknown number of 0 to many items in the dropdown menu, since it's an existing API.
Good questions, as far as I know it's been a request from theme developers to add additional breakpoints, which means it's something to consider in how we design this area, but as to how that feature might work, I think issues like this one are good places to explore the ideas! I can imagine arguments for and against adding and/or capping the number of viewports available, but for now, just mentioning it as something for us to consider if redesigning this area.
So, please take my comments here as "these are things we'll need to factor in or consider", and not a push back on any particular ideas!
jobthomas commentedon Jul 30, 2026
Just came here to confirm that I think @davewhitley 's updated approach is more aligned with what I would expect. I struggled to find where to edit the responsive side only without reading testing instructions.
annezazu commentedon Oct 7, 2026
Tagging this for @WordPress/gutenberg-design to consider as we look to improve the UX of responsive styling. Of note, here's the current view:
jasmussen commentedon Oct 8, 2026
There's a balance here, let's be careful we don't tip it towards site builder biases, so let me disclose it clearly: you should almost never need to edit responsive styles. If you are editing responsive styles you are engaging in at-most a 20% use case and even then it's going to be when you're building and editing your theme. Once that's done you'll possibly never engage with it again until such a time as you switch themes. Someone in a CNN newsroom blogging multiple times per day will never and should never engage with the responsive option.
Even if you are a theme designer, you still should probably be looking at other options than the responsive styles toggle. If you're designing a pattern, if you can find an intrinsic-responsive path to your goal rather than a media-query-based one, your pattern will work also if it's inserted inside a narrow column. So these query based responsive styles are new and shiny, long-overdue. But they aren't the perfect solution.
Does that mean the current interface—already refined for clarity, with only a single checkmark in the menu—is perfect? No, but it does mean we should be careful with how much prominence we give this toggle. I'm not sure we should shout it from the roof-tops. In fact before we give it the added prominence the splash of blue that a ToggleControl would give it, I would extricate "Preview in new tab" from this menu, to live elsewhere: that could let this dropdown be primarily about breakpoint editing.
This is my personal design feedback on this. It's valid, but it's biased towards something I'm not sure we should emphasise until other more writing-flow related improvements have landed. Is that fair?