Repository navigation
Responsive Styling – UX improvements #81226
Description
What problem does this address?
Responsive Styling in 7.1 (PR #75121) is a genuinely useful feature, and it will be helpful for many people. After testing it in WordPress Playground, I ran into several interface issues that made it hard to use with confidence. I outlined these in the RC feedback forum, and other community members raised related concerns on the call for public testing post.
My perspective comes from working with a team that supports several thousand WordPress sites in a multisite network at a higher education institute. A couple reasons why this use case matters:
- Multisite networks are widespread and would benefit from more presentation in Core UX decisions.
- Large multisite networks are how many big organizations run WordPress, spanning higher ed (Harvard, UW–Madison, NC State, UC Santa Cruz), government (NASA), media (CNN), and WordPress's own make.wordpress.org (more examples).
- The editors are usually not developers or experienced web creators, so any added editor complexity lands on a central support team at scale. A small point of confusion becomes many tickets, not one.
The problems group into three areas:
Problem 1: The device menu is difficult to understand
Turning on responsive editing and choosing which viewport to view and edit both live in the same dropdown, and both are shown with a checkmark. So the menu can display two checkmarks that mean different things: one is "the viewport I'm looking at," the other is "responsive editing is on." It's difficult to tell, at a glance, what state you're actually in. With a checklist, it also feels like I should be able to select multiple viewports at one, but only one is allowed at a time.
Problem 2: It's hard to tell which viewport you're currently editing
When responsive editing is on, a small badge in the block inspector shows the active viewport (for example, Tablet). But it sits near the top of the panel, so once you scroll down to the control you want to change, the badge is out of view.
It's easy to edit the wrong breakpoint, or to edit something while responsive styling mode is on, without realizing.
A related problem is that Desktop, Tablet, and Mobile look like three equivalent choices, but they don't behave the same way. Desktop is the base that applies to every screen size, while Tablet and Mobile are overrides layered on top of it. That difference isn't clear in the current interface, so it isn't obvious that editing on Desktop changes all sizes, or that the real responsive task is adjusting Tablet and Mobile to override Desktop.
Problem 3: When responsive editing is off, per-viewport styles are invisible
Once responsive editing is turned off, there's no indication that a block has tablet or mobile styles set. Nothing appears on the block, in the block settings, or in List View. The styles still affect the live site, but the editor gives no sign they exist. If an editor asks "why does this look wrong on mobile?", someone opening the page on desktop sees a normal-looking block and has no way to find the override without turning the mode back on and checking each viewport one at a time. The same gap causes confusion when a site changes hands or a second person edits a page.
This is compounded by a gap between viewing and editing, and by where the feature lives. Previewing a smaller screen size shows the responsive styles applied, but you can't change them from preview. You first have to turn responsive editing on. And because responsive editing is enabled from the "View" dropdown, alongside unrelated items like "Show template," it isn't clear where someone would go to edit those styles even once they can see a block has them.
What is your proposed solution?
Problem 1
-
Make Desktop / Tablet / Mobile a single segmented toggle (switcher) so it's visually clear that only one viewport is selected at a time, with helper text confirming the scope (for example, "Styles apply to tablet only").
-
Make "Responsive editing" a separate toggle switch, distinct from the viewport selection, so the mode and the viewport read as two different things rather than two lookalike checkmarks. When responsive editing is turned on it starts on Tablet (the first override of the Desktop base). When it's turned off it returns to Desktop, the base that applies to all sizes. This matches how the desktop-first cascade works.
Demo: For illustrative purposes
responsive-styling-view-toggles.mov
Problem 2
When responsive editing is on, show a persistent pill at the top of the editor that stays in view no matter how far you scroll, so it's always clear you're in a mode where styles behave differently from normal preview. Reinforce it with a colored outline around the editing canvas as an ambient signal that responsive editing is active. Include an "X" on the pill as a quick action to exit responsive editing.
The pill's label reflects the current viewport: "Editing Tablet styles" or "Editing Mobile styles" when you're overriding a smaller size, and "Editing all screen sizes" on Desktop.
The "Editing all screen sizes" label for Desktop helps account for Desktop remaining in the switcher (see problem 1): it makes clear that editing on Desktop changes every size, because Desktop is the base, rather than being just another responsive viewport.
Starting responsive mode on Tablet avoids confusion at the onset, but switching to Desktop in responsive mode gives clear feedback instead of nothing at all.
Demo: For illustrative purposes
responsive-styling-persistent-notice.mov
Problem 3
Surface responsive styles wherever a user is already looking, so they are visible even when responsive editing is off:
- In List View, show a small device icon next to any block that has tablet or mobile styles, so an entire page can be audited at a glance without entering responsive mode.
- When a block with responsive styles is selected, show a notice at the top of the block settings ("Has Tablet styles," "Has Mobile styles," or "Has Tablet and Mobile styles") with an options (⋮) menu for acting on them, for example editing or clearing them. This gives a clear, in-context path to the styles and answers "where do I go to change these?"
Demo: For illustrative purposes
Activity
talldan commentedon Aug 5, 2026
Thanks for the feedback! I left some rough notes.
Sorry if my feedback sounds harsh, but my feeling is that this change doesn't add much, and it makes the accessibility of the popover worse. A regular menu is much easier to navigate vs multiple nested widgets in a popover. The side-by-side text could wrap when localized. In the future there's also a desire to support a variable number of custom breakpoints.
We could possibly experiment with disabling the desktop option when responsive editing is enabled. Copy could be improved further.
If the radio options in menus aren't clear enough, there might be a broader design system issue.
I personally think it might be good to try something like this. There was some disagreement about it previously, because some felt it draws too much attention to the canvas, but most style changes are made in the sidebar. It might lead users to think that changing block order, or updating block content only applies to a specific breakpoint. I think if the copy is right it might be ok.
The pill shouldn't cover content, but that's a nitpick. 😄
I like some aspects about these suggestions, but I think the thing to take into account is how busy these parts of the UI get when combined with some other states
List View (html anchor + image preview + locked + hidden):
Block card - (editing a pattern + hover state active + hidden block):
I think these UIs now need some broader improvement. Perhaps a single way to convey block status.
annezazu commentedon Aug 5, 2026
Thanks so much for taking the time to share the feedback here and including different prototypes for how to solve some of these problems. It's really helpful and I agree there's lots to iterate on for 7.2.
Just connecting dots to this issue I opened based on your initial forum post that touches on this #81050 As you'll see there and in Dan's comment about, it's tricky to figure out what and how much to add to List View.
I also agree with Dan that there's something to explore here. It's almost so smooth right now that you don't even realize you've switched! Sometimes good visual friction is exactly what's needed.
tellthemachines commentedon Aug 6, 2026
I agree the current UI isn't ideal, but we need the list of breakpoints to be in a shape that's extendable, because in the future we may want to enable theme authors to define multiple custom breakpoints. So a segmented toggle won't work in that scenario.
To be honest I don't love the preview dropdown to begin with 😅
@kedarjoyner I'd love to know, given your multisite network experience, whether you think this dropdown worked well before responsive styles? Were users able to find it easily, and was it useful just for previewing pages at different screen sizes? (My concern when we decided to leverage it for responsive styles was that people might not find it, or think to look there for viewport-specific controls.)
I'm very unsure about this one, because I expect responsive styling to be applied mostly at the global styles level (for instance, ensuring that all the Heading blocks are centred on small screens) and at the template level (to define the reflow of a multi-column layout, or the height of a hero image), and very sparingly if at all in the actual content. While this could potentially be of use at the template level, we already have some inbuilt responsive behaviour in some container blocks (Columns and Grid for example) that would not be reflected as an added "responsive style". I'm reluctant to down a very long rabbit hole in trying to determine what should be shown and how, when we have no clear indication of benefit, so it might be better to wait a while and see what pain points pop up in actual use.
jasmussen commentedon Aug 6, 2026
Good issue, thanks so much for testing and reporting, and kudos for fantastically reviewable videos. And thanks to folks already commenting, I'm finding myself nodding with aspects of all of you. I will miss some bits, so let me know if I lack nuance in the thoughts below.
The multiple checkboxes in the dropdown: this is valid, and a good thought. Dan asks if it's a design system issue, I'd validate that it probably is. For that reason, CC: @WordPress/gutenberg-components
To expand a bit, the current dropdown is an older component. In fact we have a newer one that features actual radio-dots instead of checkmarks:
However I also believe those radios are possibly disappearing again in a refactor (#79560), so if those radios feel worth keeping, that is useful feedback to share at this point.
On making it clearer which viewport you are editing: Also valid! How precisely to do that, we can try things, some good ideas are already shared. Some additional thoughts to ponder as we experiment in this space:
Consider that with the adminbar always there, the grey blob that currently opens the command palette will likely go away in favour of something simpler, so there could be room if that's an accessible path forward:
On the problem of which blocks have responsive styles, that is also extremely valid.
As I responded on 80150, and as mentioned already by Dan, the List View is a crowded place. We can try to add something there, but it's non-trivial. But importantly: it's perhaps not obvious enough since the List View is not shown by default.
So far, the best solution I've seen for it is the in-canvas notes outlined in #76996. It's possibly a larger undertaking, though I do have a proof of concept PR that so far only touches on hidden blocks in #78880. Give it a shot and let me know if that resonates: if yes, the Notes tray would become a container not just for human authored notes, but for linting notes as well, such as hidden block, or insufficient contrast, or header has mobile styles.
kedarjoyner commentedon Aug 13, 2026
@jasmussen I plan to respond more thoughtfully to the wonderful feedback everyone has shared here tomorrow, but I wanted to post an update that I've commented on #79560 with the feedback about the check icon being used for radio selections. Thank you for connecting the dots here!
jupa8712 commentedon Aug 14, 2026
Responsive styles inheritance across breakpoints.
I have a comment: if I add different styles, for example, for tablets, it would be more like the styles are maintained on mobile, and I wouldn’t have to repeat the settings on mobile. This would make page layout much more practical, and the markup < — wp:xxx — > would be much shorter. Do you plan to also make it work for the number of columns per viewport? That would be very useful, especially since it also depends on the markup. I’ve been building websites with Gutenberg for several years, and what I always need most is to be able to freely structure columns and grids according to the viewport and thus control the size of things, because generally the text and image styles always stay the same. Thank you very much for everything.
kedarjoyner commentedon Aug 15, 2026
Thanks for the follow-up @talldan!
Not harsh! This conversation is exactly what I was hoping for. You've convinced me here, and it's helpful to know there's a desire to support more breakpoints in the future.
I do think the radio options using check icons makes the menu options less intuitive. Joen shared that there's a newer Menu component, but that the radio icons might be deprecated. I've shared this feedback in #79560 in hopes it can be addressed at the design system level. That would be a helpful UX win here.
That's a fair point that the canvas-wide signal with a pill button might lead users to believe that any edit they make will modify the current view they are in. Chatting briefly with another developer on our team, they wondered the same thing, and went so far as to suggest that maybe the responsive style setting should actually be something the user enables in the block Styles panel, rather than the Preview options. Not saying that's the right move, just sharing the train of thought around the topic.
kedarjoyner commentedon Aug 15, 2026
@tellthemachines I agree, and it's helpful insight that you had some concerns about this initially. The tl;dr is that I would say no from a discoverability perspective. People don't notice it's even there.
A common question we often receive in our weekly office hours and monthly lunch and learns is, "How can I preview my site on mobile?" It's something our team noted early on, when building our block theme, that we would need to teach users where it lives because it's not easy to find. In office hours, I often show people the feature as a helpful tip, and I'd say 99% of the time they did not know about it. They'll often say, "Oh, I didn't know I could do that! That's so helpful!"
I'm curious what an incremental improvement could look like to give the menu more affordance in the editor. I think a label would be helpful, but that would seem to break the current UI pattern for additional settings outside of the Public/Save button. Are there other ideas you've considered related to this one?
preview-label.mov
kedarjoyner commentedon Aug 15, 2026
@jupa8712 I think this is really great feedback. Webflow's editor takes the same cascading approach for their responsive design feature:
@annezazu I wonder if you would suggest these two items shared here be separate GitHub issues?
kedarjoyner commentedon Aug 15, 2026
@jasmussen Thanks again for sharing your feedback here, it's helpful to hear your perspective on this with how much knowledge you have across the design of the WordPress system overall.
This is a good thought, but some anecdotal fodder: We did some user testing recently where we notified users about a state change using the Snackbar component and all 4 of them did not notice it. We went with the Notice component instead. I like the Snackbar for lower priority messages, but it would likely get missed for higher priority messages where some visual friction could be useful like responsive styling.
In terms of scoping though, I assume this is a lower effort change and is still better than the current state! It could be a useful near-term UX improvement if core team members were open to this.
This is the most compelling option to me if the command palette is indeed going away. The placement at the top is much more discoverable than the Snackbar. Do you happen to know if there is a GitHub issue that I could follow where this is being considered?
I know this is a larger change and will likely take more time to integrate into Core if it moves forward, but overall is a very interesting idea that I'm curious to continue following. I've tested this locally and have a few comments and questions, but I will place them in #76996 for tracking!
21 remaining items
ramonjd commentedon Sep 16, 2026
+1 to the footer. Thanks! To me it seems like a good start pending other design directions. There's plenty of space (it's only shown on wider viewports though), and I suppose it could sit over very long breadcrumbs?
jasmussen commentedon Sep 16, 2026
I think the footer is one path forward, just one ingredient of many. I still feel like there are additional things we should do, but that shouldn't block this effort.
tellthemachines commentedon Sep 16, 2026
That shouldn't matter because at the point the footer disappears, responsive editing controls do too 😅
andreawetzel commentedon Sep 16, 2026
The footer notice is a nice addition. One thing to note is that folks can currently disable the visible footer in user preferences.
kedarjoyner commentedon Sep 16, 2026
@talldan Apologies for the delayed response here, I'm catching up on changes! This is already merged into the project, and it's definitely an improvement, I just wanted to note for groups like ours who have strict branding and federal accessibility requirements, we disable the pseudo state options because it risks thousands of users making inaccessible choices. So I believe other multi-site networks like ours will not see this update unless they allow users to make those pseudo customizations.
In a future iteration, it would be useful if it didn't require themes to have the pseudo state options enabled in order to see the responsive style pills in that area. It's helpful that (it sounds like) the footer area will show when responsive styling is on, as well as what viewport width is selected, so that users still see something within the editor view.
kedarjoyner commentedon Sep 16, 2026
@talldan These are great options. I much prefer the on canvas approach, because we know from user testing in our theme that users rarely see toast messages at the bottom of the screen, and the footer area is even less noticeable. However! I still think this is a step in the right direction, and allows us to iterate on more approaches once the change is in place. I could see both the footer approach and on-canvas approach co-existing in a future iteration.
talldan commentedon Sep 17, 2026
You should still see the badges in the inspector even without pseudo options active. Let me know if there might be a bug we're missing.
kedarjoyner commentedon Sep 17, 2026
@talldan Awesome! I spoke with another team member yesterday - we're going to test this soon and will file a bug if we find this to be true. Again, just want to share that this is all a great path forward; I really appreciate your design efforts here!
moustakalis commentedon Sep 23, 2026
On the segmented toggle vs. custom breakpoints point (@tellthemachines, @talldan): I ran into exactly this in a plugin where sites define their own breakpoints (Spacery, I'm the author), so sharing what I found in case it helps.
Counting breakpoints turned out to be the wrong test. Four short labels (Sm / Md / Lg / Xl) fit a 250px inspector column, four long ones (Widescreen / Desktop / Laptop / Handheld) don't. What I ship now: segmented when there are at most four labels and they fit a length budget, a dropdown otherwise. So a switcher and custom breakpoints don't have to be either/or, but the fallback has to be there from the start, and translated labels make the budget harder to predict.
For problem 2, two things helped in my panel:
I haven't tested either with non-technical editors at the scale @kedarjoyner describes, so take it as one data point.
JaydenCampEdge commentedon Sep 30, 2026
Hello, first time commenter so my apologies if this is in the wrong place or there's a better spot for feedback but I didn't want to double-up anywhere, let me know otherwise! Just want to bump @jupa8712's feedback; a few days ago I built a site for a client fully using the responsive styles feature- which can I say is an amazing step forward for the Wordpress editor. The only issue is that 95% of the changes I made for tablet responsiveness ended up needing to be applied to the mobile breakpoint, this led to a lot effort duplication applying changes to tablet and mobile. The majority of this was just column/grid/padding reorganisation/wrapping/distribution but it does add a level of tedium to page building. If changes only needed to be tablet applied I think it would still be better they cascade and I revert them manually for mobile, I feel there's a wider use case in that logic.
tldr: Love what you're doing, strongly support the previous feedback from @jupa8712. Thanks!
talldan commentedon Sep 30, 2026
An option in theme json could be a possibility for this, it could change how the breakpoints are generated so that they overlap.
I expect most of the challenges will be with generating the correct CSS - e.g. if there's a rule set at mobile and tablet then they need to override correctly. Some styles have more intricate rules for this too, for example if they need to unset specific CSS values to work correctly.
I think right now the priority should be getting the existing responsive tools working as well as possible, and then we can loop back to requests like this, more breakpoint extensibility (beyond just mobile and tablet) and mobile first.
JaydenCampEdge commentedon Sep 30, 2026
True, something like settings.viewport.cascadeStyles = true could omit the
480px <from the generated responsive style css in the tablet breakpoint@media (480px < width <= 782px) {(ignore my naivety here, I have no idea how complicated the css generation is, i'm just spitballing haha)I agree, it's not an actual issue or prevents site building in any way, just a preference. Thanks!
jupa8712 commentedon Sep 30, 2026
@talldan @JaydenCampEdge
You make a valid point about priorities. However, Gutenberg was created as a native alternative to other editors (like Elementor and Oxygen) and CMS platforms (like Webflow), all of which utilize style inheritance. I do believe this should be a high priority; since that is how other editors operate, people looking to start using Gutenberg will find it requires more effort and will likely prefer using non-native editors instead.
davewhitley commentedon Oct 1, 2026
@moustakalis I like how in your plugin you can edit the breakpoints or stick with the theme breakpoints. I think 4 breakpoints is enough to cover almost all cases.
I think a strong case for either cascading or separate breakpoint editing should be made sooner rather than later. This decision has big implications later, even if we do add support for both in theme.json. Users' expectation will be broken if we change it, and settling it now is better.
I personally expect the changes to cascade, and I also think most of my tablet changes also apply to mobile (but there should be a way to edit tablet-only). If cascading is truly off the table, the next best option might be an explicit "also apply to smaller breakpoints" toggle when editing at Tablet.
But that is just me personally, and with user testing this could be settled pretty easily I think!
tellthemachines commentedon Oct 2, 2026
I'm afraid it's too late to change the current behaviour, because it's already in core since 7.1 and changing it would break back compat. The best we can do is add an option to enable cascading styles in theme.json, but the default will have to remain as it is.