Enable viewport state values for Gallery aspect ratio

[tellthemachines]

What?

Part of #80388.

Enables setting tablet and mobile values for the Gallery aspect ratio control. Works with both flex and grid gallery variations.

The custom control needs to be preserved here (instead of standardising to aspect ratio block supports) because the Gallery sets aspect ratios for all its images by inlining the style in each img element, which works both for regular and dynamic galleries.

As elsewhere, the viewport-specific styles use !important to override the inline base styles.

Testing Instructions

1. Add a Gallery block with some images. Try setting aspect ratio for desktop, tablet, mobile.
2. Try the same for the Gallery Grid variation.
3. Save and check the front end.

responsive_aspectratio.mp4

Use of AI Tools

used claude opus 5; human reviewed by me.

[github-actions]

Size Change: +187 B (0%)

Total Size: 7.92 MB

📦 View Changed

Filename	Size	Change
build/scripts/block-library/index.min.js	371 kB	+187 B (+0.05%)

_{compressed-size-action}

[github-actions]

🤖 PR meta 🤖

📦 Bundle size

Size Change: +295 B (0%)

Total Size: 8.21 MB

📦 View Changed

Filename	Size	Change
build/scripts/block-library/index.min.js	364 kB	+295 B (+0.08%)

_{3839900 Run}

⚡ Performance

Show the results

Client side metrics exclude the server response time.

front-end-block-theme

Metric	150de81	trunk	% Change
timeToFirstByte	53.75 ms +14.14% -2.14%	56.05 ms +6.33% -4.37%	-4.1%
largestContentfulPaint	96 ms +6.25% -8.33%	96 ms +4.17% -6.25%	0%
lcpMinusTtfb	35.95 ms +20.03% -2.64%	37.95 ms +16.21% -10.41%	-5.27%
wpBeforeTemplate	26.58 ms +17.19% -0.79%	27.44 ms +16.25% -2.73%	-3.13%
wpTemplate	23.15 ms +5.27% -2.85%	24.31 ms +1.69% -6.75%	-4.77%
wpTotal	49.88 ms +14.17% -1.86%	51.89 ms +7.32% -3.89%	-3.87%
wpMemoryUsage	7.53 MB +0% -0%	7.49 MB +0% -0%	0.46%
wpDbQueries	17 +0% -0%	17 +0% -0%	0%

front-end-classic-theme

Metric	150de81	trunk	% Change
timeToFirstByte	44.45 ms +7.54% -1.57%	40.7 ms +4.79% -1.23%	9.21%
largestContentfulPaint	100 ms +4% -0%	88 ms +4.55% -0%	13.64%
lcpMinusTtfb	55.8 ms +1.61% -2.69%	47.7 ms +6.6% -2.62%	16.98%
wpBeforeTemplate	23.53 ms +2.55% -0.68%	23.9 ms +3.72% -1.51%	-1.55%
wpTemplate	17.69 ms +2.32% -2.43%	13.77 ms +2.69% -3.12%	28.47%
wpTotal	41.31 ms +7% -1.5%	37.59 ms +5.59% -0.96%	9.9%
wpMemoryUsage	6.15 MB +0% -0%	5.97 MB +0% -0%	2.89%
wpDbQueries	14 +0% -0%	10 +0% -0%	40%

media-processing

Metric	150de81	trunk	% Change
mediaProcessingJpeg	415.54 ms +1.18% -1.87%	411.92 ms +1.35% -0.17%	0.88%
mediaProcessingAvif	6203.64 ms +0.31% -0.19%	6169.6 ms +0.04% -0.22%	0.55%
mediaProcessingJpegToAvif	4320.18 ms +0.3% -0.38%	4313.2 ms +0.18% -0.22%	0.16%

media-upload

Metric	150de81	trunk	% Change
jpegUploadProcessing	1471.05 ms +33.94% -1.77%	1422.74 ms +0.98% -0.51%	3.4%
pngUploadProcessing	215.05 ms +5.38% -3.26%	214.99 ms +3.14% -3.83%	0.03%
largeJpegUploadProcessing	1413.04 ms +1.74% -0.27%	1412.9 ms +0.27% -0.62%	0.01%
multipleImageUploadProcessing	1586.89 ms +1.63% -1.39%	1573.79 ms +0.46% -0.76%	0.83%

post-editor

Metric	150de81	trunk	% Change
serverResponse	534.25 ms +0.83% -7.87%	516.98 ms +4.95% -6.15%	3.34%
firstPaint	237.26 ms +20.85% -12.34%	238.06 ms +12.94% -7.73%	-0.34%
domContentLoaded	1095.5 ms +1.13% -0.71%	1088.6 ms +1.19% -0.38%	0.63%
loaded	1096.78 ms +1.16% -0.71%	1089.85 ms +1.18% -0.38%	0.64%
firstContentfulPaint	456.55 ms +9.32% -4.03%	439.7 ms +3.18% -1.69%	3.83%
firstBlock	3272.91 ms +0.55% -1.27%	3280.24 ms +0.98% -0.88%	-0.22%
type	20.2 ms +4.65% -3.91%	21.53 ms +1.72% -3.9%	-6.18%
typeWithoutInspector	19.71 ms +2.23% -1.57%	21.31 ms +2.3% -4.69%	-7.51%
typeWithTopToolbar	25.61 ms +2.38% -2.73%	27.37 ms +0.66% -9.79%	-6.43%
typeContainer	8.36 ms +19.86% -7.54%	9.27 ms +4.1% -12.51%	-9.82%
focus	80.17 ms +8.73% -2.69%	80.19 ms +7.68% -3.25%	-0.02%
firstFocus	213.56 ms +0% -0%	222.11 ms +0% -0%	-3.85%
selectAll	554.53 ms +0.11% -7.2%	533.66 ms +5.15% -3.48%	3.91%
listViewOpen	71.59 ms +12.28% -9.36%	76.43 ms +6.5% -1.49%	-6.33%
inserterOpen	21.97 ms +17.52% -3.28%	23.89 ms +9.96% -10.17%	-8.04%
inserterHover	2.93 ms +19.11% -17.41%	2.87 ms +13.24% -6.62%	2.09%
inserterSearch	7.79 ms +6.93% -3.85%	7.91 ms +3.41% -7.59%	-1.52%
loadPatterns	634.28 ms +3.83% -4.46%	644.39 ms +6.39% -1.55%	-1.57%
wpTotal	523.7 ms +0.8% -8.02%	507.07 ms +4.97% -6.34%	3.28%
wpMemoryUsage	13.06 MB +0% -0%	13.03 MB +0% -0%	0.28%
wpDbQueries	54 +0% -0%	54 +0% -1.85%	0%

site-editor

Metric	150de81	trunk	% Change
serverResponse	397.86 ms +2.9% -3.85%	400.28 ms +1.19% -1.73%	-0.6%
firstPaint	239.76 ms +9.49% -14.39%	232.98 ms +13.51% -5.43%	2.91%
domContentLoaded	1092.5 ms +2.46% -1.21%	1095.66 ms +0.79% -1.61%	-0.29%
loaded	1093.66 ms +2.46% -1.21%	1096.72 ms +0.8% -1.61%	-0.28%
firstContentfulPaint	439.51 ms +3.3% -1.89%	437.53 ms +2.12% -0.43%	0.45%
firstBlock	3892.35 ms +0.55% -1.74%	3857.51 ms +1.05% -0.1%	0.9%
type	18.91 ms +3.97% -4.6%	18.59 ms +6.83% -2.31%	1.72%
navigate	105.87 ms +8.4% -5.17%	103.11 ms +9.61% -2.11%	2.68%
loadPatterns	1194.37 ms +12.7% -6.61%	1185.43 ms +7.18% -2.34%	0.75%
loadPages	1124.56 ms +0.98% -0.63%	1069 ms +1.05% -1.04%	5.2%
wpTotal	387.16 ms +2.9% -3.96%	389.66 ms +1.15% -1.74%	-0.64%
wpMemoryUsage	12.02 MB +0% -0%	11.97 MB +0% -0%	0.41%
wpDbQueries	43 +2.33% -0%	43.5 +1.15% -1.15%	-1.15%

_{3839900 Run}

🏁 Flaky tests

Show the failures

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.

Should navigate inner blocks with arrow keys in /test/e2e/specs/editor/various/writing-flow.spec.js, passed after 1 failed attempt.

TimeoutError: locator.click: Timeout 10000ms exceeded.
Call log:
  - waiting for getByRole('listbox', { name: 'Blocks' }).getByRole('option', { name: 'Paragraph' })

    at WritingFlowUtils.addDemoContent (/home/runner/work/gutenberg/gutenberg/test/e2e/specs/editor/various/writing-flow.spec.js:1482:5)
    at /home/runner/work/gutenberg/gutenberg/test/e2e/specs/editor/various/writing-flow.spec.js:30:3

_{3839900 Run}

[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: tellthemachines <isabel_brison@git.wordpress.org>
Co-authored-by: ramonjd <ramonopoly@git.wordpress.org>
Co-authored-by: andrewserong <andrewserong@git.wordpress.org>

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

[ramonjd]

Nice, working well for me so far.

One difference between this PR and trunk. When clicking through the breakpoints in the dropdown, the block inspector panel remains active until I click on "Desktop" and the list view appears.

Kapture.2026-09-09.at.15.28.27.mp4

It's not a blocker for this PR, but I imagine it could get annoying. Maybe a follow up.

Also for an optional follow up: I noticed the the crop toggle does nothing whenever a ratio is set. Wondering if it should be disabled or 🤷🏻

[ramonjd]

Might need double-checking, but from what I can see, cover applies to current blocks, but if I add a new block and save, the new block won't get it.

Maybe we could return both these properties in buildImageAttributes? 🤔

[tellthemachines]

oh well spotted!

[tellthemachines]

fixed

[ramonjd]

I was testing out this regex to see if we could prevent drift between the two (PHP and JS) and had a bit of a TIL moment.

If we drop shorthand for decimal units /d and spaces /s like this

^(auto|[0-9]+(\.[0-9]+)?([ \t]*/[ \t]*[0-9]+(\.[0-9]+)?)?)$

it is byte-identical across JS and PCRE.

E.g., JS \s matches Unicode spaces, PHP's \s doesn't. [ \t] mean the same in both engines.

https://www.pcre.org/original/doc/html/pcresyntax.html#SEC4

Pretty edge casey

[tellthemachines]

where would we store it to reuse across JS and PHP though? if it's still duplicated there's always the chance of drift

[ramonjd]

Oh no I just mean to swap out the shorthands in both. Keep both, but make their output 1:1 across engines.

Not a blocker, just a rabbit hole I went down. So long as we have tests for the expected cases I think it should be fine.

[tellthemachines]

the block inspector panel remains active until I click on "Desktop" and the list view appears

"active" how? keyboard focus is on the preview dropdown while switching viewports.

[ramonjd]

"active" how? keyboard focus is on the preview dropdown while switching viewports.

It's in the video I posted. The block inspector styles panel closes when you go from "Tablet/Mobile" to "Desktop" and you end up on the list view. This doesn't happen in trunk. I wrote "active" when I meant "visible".

[tellthemachines]

The block inspector styles panel closes when you go from "Tablet/Mobile" to "Desktop" and you end up on the list view. This doesn't happen in trunk.

I can't see any difference between this branch and trunk in my testing. I agree it would be nicer if we stayed on the styles tab when switching to desktop, but that behaviour is same on this branch as on trunk, and on 7.1. Am I missing something?

[ramonjd]

I can't see any difference between this branch and trunk in my testing. I agree it would be nicer if we stayed on the styles tab when switching to desktop, but that behaviour is same on this branch as on trunk, and on 7.1. Am I missing something?

Thanks for double checking. Nope you're missing nothing. I don't know what I was doing that convinced me of that, but I withdraw that comment.

Sorry for the confusion!

[andrewserong]

This is testing wonderfully for me!

✅ Aspect ratio set at desktop, tablet, and mobile
✅ Static and dynamic gallery blocks
✅ In editor and site frontend in Chrome, and site fronted in Safari and Firefox

Quick excerpt of testing (16/9 at desktop, 1:1 at tablet, original at mobile):

2026-09-11.17.24.46.mp4

Left a couple of minor questions/nits but nothing showstopping.

Nice work rolling out aspect ratio to the viewports, and it's really neat being able to override back to the original ratio 🚀

[andrewserong]

Tiny nit: is checking that it's a truthy string enough for this case, or would it be worth passing it through the isValidGalleryAspectRatio function that this PR adds?

[tellthemachines]

Good question! I think the current check is enough here because we're only dealing with whether the control has a value set, whereas isValidGalleryAspectRatio is needed at the point we're outputting the actual CSS.

[andrewserong]

Not at all a blocker for this PR, but just wondering for polish if it'd be worth adjusting this label if a viewport has been applied so that it's clear that the aspect ratio applied is affecting a particular viewport?

Currently it claims that the gallery images have been updated to a particular aspect ratio, but technically this is "the gallery in a particular viewport is now set to display its inner images at a particular aspect ratio, but those inner images haven't actually been updated in this mode". Obviously that's a bit too wordy 😄

A couple of options:

• Don't display a success notice at all when adjusting the viewport aspect ratios since the inner blocks themselves do not get updated. Or, use a string like the following:
• 'Gallery images in the tablet|mobile viewport will be displayed in the aspect ratio: %s'

[tellthemachines]

good idea, done!

[andrewserong]

This is pre-existing (i.e. the line here has just moved up in this file so it was the same on trunk), but I think in this array, the WP_Theme_JSON output winds up winning, because it gets called last? If we ever have different logic for get_viewport_media_queries in Gutenberg vs core, could this function be calling the core version unintentionally instead of the Gutenberg version?

Feel free to ignore if this is a non-issue!

[tellthemachines]

If the Gutenberg class exists, the loop will break before it ever reaches WP_Theme_JSON so that shouldn't be an issue!

[ramonjd]

Heads up - I rebased this PR!

Retested and it's working well. New galleries, existing... all good. Thanks!