Correct behaviour of flex child fixed width and introduce max width option by tellthemachines · Pull Request #79073 · WordPress/gutenberg

tellthemachines · 2026-06-10T07:53:13Z

What?

The existing "fixed" option in flex child layouts in reality works as "max width", because it doesn't prevent shrinkage of the blocks it's applied to. This has caused confusion and there have been multiple requests for a "fixed" option that is actually fixed.

This PR solves the issue by renaming the existing "fixed" behaviour "max width", and allowing "fixed" to be unshrinkable by adding flex-shrink: 0 to fixed blocks.

There should be no back compat issues; blocks currently set to "fixed" will automatically become "max width", using the same fixed attribute value as before. The new "fixed" behaviour uses a new attribute value fixedNoShrink 😄

Testing Instructions

Create a Row block with children and set one to "fixed" size on trunk;
Switch to this PR; the "fixed" block should now be max width and its behaviour unchanged;
Try setting another Row child to "fixed" and check that its size doesn't go under the stipulated size when the screen resizes.

Screenshots or screencast

The options are starting to look a little tight, but I'm not sure if there's a better component to use here. Suggestions welcome!

Use of AI Tools

Used codex/gpt 5.5

github-actions · 2026-06-10T08:01:21Z

Size Change: +251 B (0%)

Total Size: 8.59 MB

📦 View Changed

Filename	Size	Change
`build/scripts/block-editor/index.min.js`	380 kB	+251 B (+0.07%)

_{compressed-size-action}

Marc-pi · 2026-06-10T11:53:39Z

the frequent need is to display a row block for a title within a cover, with a background to hightlight the text ahead of the background image...
i do use a custom css with "width: fit-content;" to minimize the text background width...
this PR does not cover this especially, but it is a strong need...

github-actions · 2026-06-10T11:53:52Z

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.

Unlinked Accounts

The following contributors have not linked their GitHub and WordPress.org accounts: @porg.

Contributors, please read how to link your accounts to ensure your work is properly credited in WordPress releases.

If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message.

Unlinked contributors: porg.

Co-authored-by: tellthemachines <[email protected]>
Co-authored-by: ramonjd <[email protected]>
Co-authored-by: andrewserong <[email protected]>
Co-authored-by: Marc-pi <[email protected]>
Co-authored-by: talldan <[email protected]>
Co-authored-by: tresorama <[email protected]>
Co-authored-by: iamtakashi <[email protected]>

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

andrewserong · 2026-06-11T07:44:52Z

Just a drive-by comment (ran out of time to review this week), but for this:

The options are starting to look a little tight, but I'm not sure if there's a better component to use here. Suggestions welcome!

Would changing the label to Max help? We already know it's about width due to the label above, so that might help it sneak into the available space?

talldan · 2026-06-11T10:25:12Z

blocks currently set to "fixed" will automatically become "max width", using the same fixed attribute value as before. The new "fixed" behaviour uses a new attribute value fixedNoShrink 😄

Yeah, it's kinda not great and I expect it will be confusing for other contributors, but I guess that's WordPress and the back compat policy 🤷

I don't have any alternative suggestions on a better solution, at least none that don't trade user experience for sensible reading code. (e.g. keeping 'Fixed' as the option and then 'Yeah, but like really fixed' as an extra checkbox. 😄 )

Code quality wise we could potentially use enum style config objects for defining the values to make it self-documenting:

// Note: max used to be called 'Fixed' in the UI but was renamed and replaced by 'fixedNoShrink'.
const WIDTH_VALUES = { fit: 'fit', grow: 'grow', max: 'fixed', fixed: 'fixedNoShrink' }

then whenever the value is check used at least it somewhat makes sense to the reader:

if ( value === WIDTH_VALUES.max )

Also adding comments wherever 'fixed' is referenced as a string could be a nice touch.

ramonjd

Thanks for picking this up

It's testing well for me in the default viewport, but the fixed override may need to explicitly emit something like flex-shrink: 1 (assuming I'm grokking the responsive overrides correctly).

then whenever the value is check used at least it somewhat makes sense to the reader:
Code quality wise we could potentially use enum style config objects for defining the values to make it self-documenting

+1 to this. It might make repeated string checks for 'fixed' and 'fixedNoShrink' easier and less prone to misread later. Something like FLEX_CHILD_SIZE.max = 'fixed' and FLEX_CHILD_SIZE.fixed = 'fixedNoShrink' perhaps?

Then the backwards compat check could be abstracted, e.g.,

export function isFlexChildSizingWithSize( value ) {
	return value === FLEX_CHILD_SIZING.MAX || value === FLEX_CHILD_SIZING.FIXED;
}

ramonjd · 2026-06-12T02:42:39Z

+		) {
 			declarations[ 'flex-basis' ] = flexSize;
+			if ( selfStretch === 'fixedNoShrink' ) {
+				declarations[ 'flex-shrink' ] = '0';


I noticed one thing while testing with responsive styles, if a responsive override switches to max width and the default is fixed, the responsive rule only includes flex-basis and it doesn’t reset flex-shrink.

I guess we need to explicitly include flex-shrink: 1;?

Is that something to look at in this PR or a follow up?

@media (width <= 480px) { .wp-container-content-067f0074 { flex-basis: 244px; // inherits flex-shrink: 0; from default/desktop } } .wp-container-content-067f0074 { flex-basis: 260px; flex-shrink: 0; }

Maybe some tests could cover the final cascade behavior

Good catch! Should be fixed now.

Nice. I can see flex-shrink: unset; now. 🌮

ramonjd · 2026-06-12T02:43:41Z

+function maxSizeLabel( parentLayout ) {
+	const { orientation = 'horizontal' } = parentLayout ?? {};
+	return orientation === 'horizontal'
+		? _x( 'Max width', 'Block with maximum width in flex layout' )


I like Andrew’s suggestion of "Max" too as a space saving measure. The help text elaborates "Specify a maximum width." anyway

Updated. It looks much better, thanks both for the suggestion!

…ption

github-actions · 2026-06-15T00:52:30Z

Flaky tests detected in d151ee3.
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.

🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/27516815341
📝 Reported issues:

[Flaky Test] should update the HTML only for the latest navigation #78835 in /test/e2e/specs/interactivity/router-navigate.spec.ts

tellthemachines · 2026-06-15T02:33:58Z

'Yeah, but like really fixed' as an extra checkbox

This would be a great April fools joke though

tellthemachines · 2026-06-15T05:58:49Z

Ok I think all the feedback has been addressed and suggestions implemented! This should be ready for a final review.

andrewserong

This is testing great for me, and nice work getting back to implementing this, I recall it being a request a long time ago (checks the linked issue: 2023!). While the internal naming might be slightly awkward, I think this is the right approach to preserving back-compat while enabling the feature.

Also, looks like Ramon's case of the base rule being "Fixed" and a mobile viewport settings a block to "Max" is working now 👍

LGTM 🚀

Co-authored-by: Andrew Serong <[email protected]>

tellthemachines requested review from andrewserong, ramonjd and talldan June 10, 2026 07:53

tellthemachines self-assigned this Jun 10, 2026

tellthemachines requested review from ajitbohra, ellatrix, fabiankaegy and juanmaguitar as code owners June 10, 2026 07:53

tellthemachines added [Type] Enhancement A suggestion for improvement. [Feature] Layout Layout block support, its UI controls, and style output. labels Jun 10, 2026

github-actions Bot added the [Package] Block editor /packages/block-editor label Jun 10, 2026

ramonjd reviewed Jun 12, 2026

View reviewed changes

Correct behaviour of flex child fixed width and introduce max width o…

eec7c1a

…ption

tellthemachines force-pushed the fix/flex-child-width branch from 1009a8c to eec7c1a Compare June 15, 2026 00:00

change label to "max"

d151ee3

fix responsive flex-shrink

fcfdb76

make code more readable

7f63765

tellthemachines mentioned this pull request Jun 15, 2026

Fix flex child fixed width and introduce max width option WordPress/wordpress-develop#12172

Closed

changelog

12523e8

andrewserong approved these changes Jun 15, 2026

View reviewed changes

Comment thread schemas/json/block.json Outdated

Update schemas/json/block.json

afccb3a

Co-authored-by: Andrew Serong <[email protected]>

tellthemachines merged commit 94137f7 into trunk Jun 15, 2026
41 checks passed

tellthemachines deleted the fix/flex-child-width branch June 15, 2026 07:22

github-actions Bot added this to the Gutenberg 23.5 milestone Jun 15, 2026

tellthemachines mentioned this pull request Jun 15, 2026

Layout: Add flex-shrink: 0 to fixed width blocks in flex layouts #70324

Closed

github-actions Bot mentioned this pull request Jun 18, 2026

PHP backports for WP 7.1 #79304

Open

Uh oh!

Conversation

tellthemachines commented Jun 10, 2026

What?

Testing Instructions

Screenshots or screencast

Use of AI Tools

Uh oh!

github-actions Bot commented Jun 10, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Marc-pi commented Jun 10, 2026

Uh oh!

github-actions Bot commented Jun 10, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Unlinked Accounts

Uh oh!

andrewserong commented Jun 11, 2026

Uh oh!

talldan commented Jun 11, 2026

Uh oh!

ramonjd left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

ramonjd Jun 12, 2026

Choose a reason for hiding this comment

Uh oh!

tellthemachines Jun 15, 2026

Choose a reason for hiding this comment

Uh oh!

ramonjd Jun 15, 2026

Choose a reason for hiding this comment

Uh oh!

ramonjd Jun 12, 2026

Choose a reason for hiding this comment

Uh oh!

tellthemachines Jun 15, 2026

Choose a reason for hiding this comment

Uh oh!

github-actions Bot commented Jun 15, 2026

Uh oh!

tellthemachines commented Jun 15, 2026

Uh oh!

tellthemachines commented Jun 15, 2026

Uh oh!

andrewserong left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

github-actions Bot commented Jun 10, 2026 •

edited

Loading

github-actions Bot commented Jun 10, 2026 •

edited

Loading

ramonjd left a comment •

edited

Loading

andrewserong left a comment •

edited

Loading