[talldan]

What?

Proposes adding viewport status info to the editor footer, including the current selected viewport and whether 'Responsive styles' is active.

Why?

This info isn't really shown anywhere, there's been some criticism that whether or not Responsive Styles is active is unclear.

How?

• Adds the info to the editor footer
• Uses the existing preference to control hiding the entire footer - updates the copy of the UI.

Note that there is now a separate PR to improve the breadcrumbs so they better handle the reduced space - Block breadcrumbs: Use @wordpress/ui package component.

Testing Instructions

1. Open the editor
2. Toggle on 'Responsive styles' and select a mobile or tablet breakpoint
3. Observe the info is shown in the footer
4. Resize the viewport - observe the footer updates

Screenshots or screencast

Use of AI Tools

OpenCode / GPT

[github-actions]

🤖 PR meta 🤖

🎉 Props

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: talldan <talldanwp@git.wordpress.org>
Co-authored-by: andrewserong <andrewserong@git.wordpress.org>
Co-authored-by: jasmussen <joen@git.wordpress.org>
Co-authored-by: ciampo <mciampini@git.wordpress.org>
Co-authored-by: aduth <aduth@git.wordpress.org>
Co-authored-by: tellthemachines <isabel_brison@git.wordpress.org>
Co-authored-by: ramonjd <ramonopoly@git.wordpress.org>
Co-authored-by: jameskoster <jameskoster@git.wordpress.org>

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

Updated as activity occurs, without notifying anyone named here. Add the props-bot label to refresh.

📦 Bundle size

Size Change: +931 B (+0.01%)

Total Size: 8.53 MB

📦 View Changed

Filename	Size	Change
build/scripts/editor/index.min.js	639 kB	+498 B (+0.08%)
build/styles/editor/style-rtl.css	32.7 kB	+108 B (+0.33%)
build/styles/editor/style-rtl.min.css	27.8 kB	+108 B (+0.39%)
build/styles/editor/style.css	32.8 kB	+107 B (+0.33%)
build/styles/editor/style.min.css	27.8 kB	+110 B (+0.4%)

_{9827f91 Run}

⚡ Performance

Show the results

Client side metrics exclude the server response time.

front-end-block-theme

Metric	e99588b	trunk	% Change
timeToFirstByte	47.7 ms +6.5% -3.14%	49 ms +14.08% -4.18%	-2.65%
largestContentfulPaint	80 ms +12.5% -0%	82 ms +7.32% -2.44%	-2.44%
lcpMinusTtfb	32.8 ms +3.96% -4.12%	32.5 ms +5.54% -3.38%	0.92%
wpBeforeTemplate	23.91 ms +7.4% -2.89%	23.98 ms +19.43% -2.96%	-0.29%
wpTemplate	19.85 ms +3.58% -4.33%	20.17 ms +2.38% -4.12%	-1.59%
wpTotal	43.84 ms +7.16% -3.24%	45.11 ms +11.97% -4.34%	-2.82%
wpMemoryUsage	7.61 MB +0% -0%	7.58 MB +0% -0%	0.47%
wpDbQueries	17 +0% -0%	17 +0% -0%	0%

front-end-classic-theme

Metric	e99588b	trunk	% Change
timeToFirstByte	39.55 ms +3.67% -3.79%	39.55 ms +3.29% -2.91%	0%
largestContentfulPaint	92 ms +0% -4.35%	92 ms +0% -4.35%	0%
lcpMinusTtfb	51.15 ms +2.25% -2.15%	50.45 ms +3.77% -1.39%	1.39%
wpBeforeTemplate	21.09 ms +5.69% -1.52%	21.02 ms +1.67% -1.33%	0.33%
wpTemplate	14.78 ms +9.27% -3.52%	15.12 ms +4.3% -3.9%	-2.25%
wpTotal	36.17 ms +4.56% -3.18%	36.48 ms +2.99% -3.12%	-0.85%
wpMemoryUsage	6.25 MB +0% -0%	6.20 MB +0% -0%	0.72%
wpDbQueries	14 +0% -0%	14 +0% -0%	0%

media-processing

Metric	e99588b	trunk	% Change
mediaProcessingJpeg	389.57 ms +0.22% -0.72%	397.42 ms +1.96% -3.17%	-1.98%
mediaProcessingAvif	5664.09 ms +0.41% -0.16%	5664.66 ms +0.36% -0.12%	-0.01%
mediaProcessingJpegToAvif	3872.06 ms +0.28% -0.26%	3859.2 ms +0.44% -0.07%	0.33%

media-upload

Metric	e99588b	trunk	% Change
jpegUploadProcessing	1424.65 ms +36.1% -0.56%	1420.57 ms +0.45% -0.18%	0.29%
pngUploadProcessing	207.34 ms +2.64% -4.73%	207.66 ms +5.25% -1.25%	-0.15%
largeJpegUploadProcessing	1409.88 ms +0.71% -0.44%	1410.11 ms +1.03% -0.22%	-0.02%
multipleImageUploadProcessing	1558.01 ms +7.75% -0.71%	1565.96 ms +1.27% -0.38%	-0.51%

post-editor

Metric	e99588b	trunk	% Change
serverResponse	264.13 ms +8.59% -7.5%	270.17 ms +5.9% -6.48%	-2.24%
firstPaint	301.44 ms +12.26% -27.47%	308.21 ms +12.37% -44.76%	-2.2%
domContentLoaded	738.04 ms +4.51% -3.43%	763.27 ms +1.85% -4.21%	-3.31%
loaded	739.13 ms +4.52% -3.4%	764.48 ms +1.83% -4.18%	-3.32%
firstContentfulPaint	345.53 ms +2.41% -6.53%	353.43 ms +3.63% -2.33%	-2.24%
firstBlock	2141.43 ms +2.52% -1.32%	2219.14 ms +1.59% -1.34%	-3.5%
type	13.79 ms +6.09% -5.29%	14.36 ms +1.81% -6.27%	-3.97%
typeWithoutInspector	13.83 ms +5.42% -6.72%	13.99 ms +9.08% -3.57%	-1.14%
typeWithTopToolbar	18.48 ms +2.38% -6.76%	16.73 ms +3.77% -6.28%	10.46%
typeContainer	6.6 ms +9.09% -5.3%	6.15 ms +4.07% -4.72%	7.32%
focus	77.76 ms +10.1% -4.89%	71.76 ms +5.42% -4.28%	8.36%
firstFocus	180.18 ms +0% -0%	147.32 ms +0% -0%	22.31%
selectAll	380.21 ms +1.46% -4.56%	370.49 ms +0.6% -0.5%	2.62%
listViewOpen	47.72 ms +8.21% -4.32%	50.6 ms +5.71% -2.51%	-5.69%
inserterOpen	27.92 ms +12.82% -6.81%	28.96 ms +7.84% -8.36%	-3.59%
inserterHover	9.36 ms +6.94% -9.08%	9.36 ms +6.84% -3.95%	0%
inserterSearch	7.2 ms +3.06% -1.25%	7.12 ms +5.62% -8.43%	1.12%
loadPatterns	460.08 ms +6.9% -3.29%	443.62 ms +1.8% -6.08%	3.71%
wpTotal	255.92 ms +8.83% -7.47%	262.08 ms +6.08% -6.98%	-2.35%
wpMemoryUsage	13.34 MB +0% -0%	13.31 MB +0% -0%	0.28%
wpDbQueries	54 +0% -0%	54 +0% -0%	0%

site-editor

Metric	e99588b	trunk	% Change
serverResponse	473.17 ms +9.03% -2.54%	497.55 ms +1.38% -3.14%	-4.9%
firstPaint	251.24 ms +95.14% -6.69%	250.52 ms +15.36% -1.8%	0.29%
domContentLoaded	1220.45 ms +0.68% -0.73%	1238.9 ms +0.71% -1.04%	-1.49%
loaded	1221.56 ms +0.67% -0.73%	1240.22 ms +0.71% -1.06%	-1.5%
firstContentfulPaint	508.03 ms +1.88% -3.49%	512.82 ms +1.9% -1.48%	-0.93%
firstBlock	4569.26 ms +1.34% -1.43%	4591.53 ms +0.98% -1.31%	-0.49%
type	16.89 ms +7.58% -2.19%	17.73 ms +0.9% -2.59%	-4.74%
navigate	115.2 ms +6.42% -2.79%	112.07 ms +10.59% -5.48%	2.79%
loadPatterns	1220.94 ms +1.88% -2.56%	1199.46 ms +5.4% -13.03%	1.79%
loadPages	1021.97 ms +2.95% -1.35%	1020.32 ms +0.86% -2.91%	0.16%
wpTotal	462.61 ms +9.1% -2.65%	486.16 ms +1.57% -3.21%	-4.84%
wpMemoryUsage	12.37 MB +0% -0%	12.36 MB +0% -0%	0.13%
wpDbQueries	43 +2.33% -0%	43 +2.33% -0%	0%

_{9827f91 Run}

🏁 Flaky tests

Some tests passed with failed attempts. The failures may not be related to this commit but are still reported for visibility. See the documentation for more information.

pre-publish panel does not dirty the default category record in /test/e2e/specs/editor/collaboration/http-only/collaboration-taxonomy-record-dirty.spec.ts, passed after 1 failed attempt.

Error: expect(received).toBe(expected) // Object.is equality

Expected: false
Received: true
    at /home/runner/work/gutenberg/gutenberg/test/e2e/specs/editor/collaboration/http-only/collaboration-taxonomy-record-dirty.spec.ts:111:25

_{9827f91 Run}

[talldan]

Ports the block breadcrumbs to the @wordpress/ui breadcrumb component

I don't know how ready this component is. So that's one concern. It does change the visual style too, which might be another. It works better than what's in trunk.

[andrewserong]

Oh, I love this!

Also nice that the footer pixel dimensions displays when the responsive styles mode is disabled, too:

One question: should you be able to click the "Responsive styles" text in the footer area to toggle it on and off? For what it's worth, I found myself clicking on it 😄

Also, the pixel dimensions updates dynamically when the viewport preview changes. I like that, but I'm vaguely wondering if anyone will expect the dimensions there to specify the limits of the breakpoint rather than the current viewport dimensions. Probably not a huge issue, but again, just capturing the thought. Here's a quick video just to show it updating as you drag the handles:

2026-10-07.17.27.57.mp4

Overall, though, of all the options we've seen so far for how to make the mode more prominent / clear that it's engaged, this is my favourite. This part of the footer is otherwise unused, and to me this strikes a good balance between making it more prominent, but not overwhelming the UI while it's active.

Keen to hear what others think, too!

[jasmussen]

This seems good at a glance. As noted in other comments, it's not the be-all end-all solution, it's one ingredient, and it's a fine one.

The only thoughts on visuals I have are unrelated and inactionable for this PR, it's mostly that I regret the footer became taller. Even if it's only 8px, it's 8x[screenwidth] and ends up feeling like a lot on small laptops. Just something for the broader group to ponder separately.

[ciampo]

It's nice to see Breadcrumb being used in the editor!

The changes to make the component more flexible (allow only a current item, allow customization of aria-current) make sense, but I don't think that switching from buttons to links is correct; links suggest navigation, while here we need to perform an action (select a block).

For this reason, I opened a separate issue to track these improvements to Breadcrumb separately, and opened a PR to implement them.

As soon as it lands, we should be able to rebase this PR and use buttons directly in Breadcrumb.

[tellthemachines]

I love this solution visually. Whether or not we may need something even more obvious 😅 this is a great addition.

Also, the pixel dimensions updates dynamically when the viewport preview changes. I like that, but I'm vaguely wondering if anyone will expect the dimensions there to specify the limits of the breakpoint rather than the current viewport dimensions.

Given how this type of feature works in browsers I would expect it to be dynamic rather than show breakpoint limits.

Just wondering if we'll need the additional preference? I almost wonder if we could simply rename the label of the showBlockBreadcrumbs feature to specify this footer area

I'd go with this at first instead of adding a new preference. We could always split them out later if it were really necessary.

Ports the block breadcrumbs to the @wordpress/ui breadcrumb component so that it has responsive behavior (it's probably worth extracting this to a separate PR first)

Agree this should be a separate PR and not necessarily before this one - things are already broken on trunk for hugely nested blocks so it could easily be a follow-up (besides, breadcrumbs and viewport previews are only available from 782px upward so the screen will never be tiny tiny when these items display and horribly bloated nesting is a bit of an edge case)

trunk:

[talldan]

I don't think that switching from buttons to links is correct; links suggest navigation, while here we need to perform an action (select a block).

No strong feelings here, but in the Document Outline and List View links are used. List View was originally button but it was changed to use links in #35655. My thought process was to make it consistent. Blocks do have an id that can be linked to via href.

Just wondering if we'll need the additional preference? I almost wonder if we could simply rename the label of the showBlockBreadcrumbs feature to specify this footer area

I'd go with this at first instead of adding a new preference. We could always split them out later if it were really necessary.

Sounds good, and makes it simpler 👍

Agree this should be a separate PR and not necessarily before this one

Yeah, I wondered about that when I saw how the original one doesn't handle things at all, but thought I'd try out the new breadcrumbs, which I think is a really good improvement. Too much for this PR though. I'll split it out into a separate PR, and then we can decide the ordering 👍

[talldan]

Ok - this PR is now simplified and the breadcrumbs changes moved to a different PR - #84295. Also switched to only using one preference.

[talldan]

One question: should you be able to click the "Responsive styles" text in the footer area to toggle it on and off? For what it's worth, I found myself clicking on it 😄

Noticed I hadn't answered this. One of the reasons I haven't done that is right now when clicked it'll disappear and the user won't be able to toggle on again from the same place. I think the only way around it is to keep the UI semi-permanently visible (could be that it's only there when a non-desktop viewport is selected). At that point it starts to feel more like duplicating parts of the viewport menu rather than just a status indicator (also, similarly, should the viewport info be clickable and interactive if the Responsive Styles text is). So I'm not completely sure about it. Maybe we listen out for feedback on this and iterate.

[ramonjd]

This is looking very nice, great to have a text cue about responsive styles when active.

wondering if anyone will expect the dimensions there to specify the limits of the breakpoint rather than the current viewport dimensions
Given how this type of feature works in browsers I would expect it to be dynamic rather than show breakpoint limits.

Not a blocker, but related to the above comments: I noticed while testing in the browser device toolbar that, around about 1280px and with both sidebars open, the iframe width is below 781, but the footer still says 781.

[ramonjd]

Sorry if this has already been covered. Responsive styles is the feature, but would something like "Editing tablet styles" describe what is happening in the editor?

[tellthemachines]

Yes that's a good point it might be better to describe what's enabled more accurately.

Also, given that currently desktop styles aren't viewport-specific, should we remove the label once we hit the desktop breakpoint when resizing the canvas?

[talldan]

I did try a few things out like this when developing but I find it makes the text quite long in the footer, and also it created a disconnection between the footer and the menu item which is called 'Responsive styles':

I also found when testing it if I have a pseudo state active then that text ends up disagreeing with what the block inspector shows:

I tried making it also mention pseudo state, but that felt a bit unusual, because that state is only applied to a single block, and the footer feels like a global area.

So I feel the best option is to keep it simple and only have the text represent that the menu item is enabled.

[talldan]

Also, given that currently desktop styles aren't viewport-specific, should we remove the label once we hit the desktop breakpoint when resizing the canvas?

The purple color is still used on the viewport icon here when on desktop, so it matches that:

But yeah, I think we can remove that from both places, and possibly also disable the 'Responsive styles' option when on Desktop. What do you think?

Happy to roll it into this PR or a follow up.

[tellthemachines]

But yeah, I think we can remove that from both places, and possibly also disable the 'Responsive styles' option when on Desktop.

Yeah that would be good for consistency! If we do implement desktop-only styles later we can always add it back.

Happy to roll it into this PR or a follow up.

Whichever is easiest!

[talldan]

This should be addressed now, let me know what you think!

[tellthemachines]

Yes I think this is better! Having to select tablet/mobile to enable responsive styles is a small tradeoff for increased clarity around which styles are viewport specific. The dropdown interaction is still not great but I don't think this makes it worse in any way 😅

[ciampo]

I don't think that switching from buttons to links is correct; links suggest navigation, while here we need to perform an action (select a block).

No strong feelings here, but in the Document Outline and List View links are used. List View was originally button but it was changed to use links in #35655. My thought process was to make it consistent. Blocks do have an id that can be linked to via href.

Thanks for the reference, I didn't have that context.

In general, links make sense for navigation within the same page, but having an id doesn't by itself settle the choice. Are these breadcrumbs intended to navigate to the block, with selection as part of that navigation, or just change the editor's selection? The current handlers cancel native navigation and call selectBlock, and the fragment doesn't directly target the block inside the iframe. Cancelling native navigation can still be appropriate if JavaScript provides equivalent navigation, so I'd base the "links vs button" choice on the intended behavior.

The changes in #84156 will give Breadcrumb consumers both link and button items, so they can choose whichever fits their use case.

[talldan]

Not a blocker, but related to the above comments: I noticed while testing in the browser device toolbar that, around about 1280px and with both sidebars open, the iframe width is below 781, but the footer still says 781.

It's a good point. I decided to hide the dimensions whenever the browser viewport constrains the canvas width.

I considered some different ways to handle it:

• Option 1 - Show the actual dimensions. That becomes tricky because the 'Tablet' / 'Mobile' info might then mismatch the dimensions. We could show whether it's physically at 'Tablet' or 'Mobile' after being constrained by the browser window, but then the info mismatches what the user has selected in the viewport dropdown. I don't know if we should consider changing that as well, it's a can of worms.
• Option 2 - Try to explain to the user when the canvas width is constrained. I tried a few different things, but it's quite a complicated thing to explain succinctly.

So I went with a third option to hide the info entirely when it's not accurate. Let me know what you think!

[jameskoster]

Not a blocker for this PR but I just wanted to +1 @andrewserong's idea about making this interactive.

I could see a zoom control living here too.

[tellthemachines]

This LGTM now!

around about 1280px and with both sidebars open, the iframe width is below 781, but the footer still says 781.

It's a good point. I decided to hide the dimensions whenever the browser viewport constrains the canvas width.

I think we have a bigger problem here (unrelated to this PR though) which is that getting into such a state with responsive styles enabled means you can select the tablet breakpoint, start styling it and not see the styles apply on canvas because the actual breakpoint being applied is mobile. I'm not sure how to best approach this; should we hide/disable breakpoints larger than the current canvas size? Something to think about and fix later.

[tellthemachines]

This is also a good improvement! It was confusing to have 'Style changes apply only to the selected viewport.' on desktop.

[tellthemachines]

Do we need to do the same check for canvasWidth?

[talldan]

I don't believe so, the width is explicitly set to a value. The height is derived from the width. I think even showing 'auto' for the height is a real edge case, I don't think it's possible for a user to trigger it, but it can logically happen and might happen if we change some rules.

[tellthemachines]

Yes I think this is better! Having to select tablet/mobile to enable responsive styles is a small tradeoff for increased clarity around which styles are viewport specific. The dropdown interaction is still not great but I don't think this makes it worse in any way 😅