Add Width and Height controls to children of flex, flow and constrained layouts

[tellthemachines]

What?

Extracts the child controls from the layout redesign prototype in #53455.

UI changes

• All children of blocks with flow, constrained or flex layout types that opt in to allowSizingOnChildren get a Width and a Height control in the Dimensions panel.
• Child blocks currently have to support Dimensions for this to work; in the future these controls will likely be moved into the Layout panel as part of #47902.
• The options available for Width and Height vary depending on the parent layout type.

Available widths

• Fixed and Fit for all blocks
• Default is specific to constrained layout children and applies content width
• Wide and Fill are available for constrained layout children that support wide and full alignment
• Fill is available for all flow and flex children as width: 100% and flex-grow: 1 respectively
• Max width is available for horizontal flex children and is equivalent to the fixed option on trunk (so not actually fixed but shrinkable)

Available heights

• Fix and Fixed for all blocks
• Fill and Max height for children of flex layouts, both horizontal and vertical.

Implementation details

• I added the parent alignment as context for InnerBlocks to be able to add Wide and Fill alignment options only when the parent block is aligned wide or full, otherwise the controls seem like they're not doing anything. That differs from alignment behaviour on trunk, which has always felt weird to me so I was keen to try out something different.
• The PHP layout logic is now checking the parent's block supports for default layout types, because the width and height values rely utterly on knowing the parent's layout type to apply the correct styles.
• The controls are using the soon-to-be-deprecated CustomSelectControl V1 but should be easy to switch once V2 becomes available.
• There's a lot of logic for selecting the default value of the controls because it's different for each layout type
• Had to look up alignment attributes and block support, as well as add an onChangeAlignment function so that wide and full alignments can be manipulated from the Width and Height controls. We should be able to remove them once these controls move to the Layout panel because the block editor's DimensionsPanel is still a private API.

Testing Instructions

1. Add a Group block with some children to a post or template;
2. Check that the children have Width and Height controls in the sidebar under Styles > Dimensions (the child must support Dimensions for this to work);
3. Play with Width and Height settings;
4. Try transforming the Group into a Row or Stack and notice changes in Width and Height possibilities.
5. Save and check that the front end styles match the editor ones.

Testing Instructions for Keyboard

Screenshots or screencast

[github-actions[bot]]

Size Change: +1.08 kB (0%)

Total Size: 1.71 MB

Filename	Size	Change
build/block-editor/index.min.js	253 kB	+1.08 kB (0%)

ℹ️ View Unchanged

Filename	Size
build/a11y/index.min.js	955 B
build/annotations/index.min.js	2.69 kB
build/api-fetch/index.min.js	2.32 kB
build/autop/index.min.js	2.1 kB
build/blob/index.min.js	578 B
build/block-directory/index.min.js	7.26 kB
build/block-directory/style-rtl.css	1.03 kB
build/block-directory/style.css	1.03 kB
build/block-editor/content-rtl.css	4.43 kB
build/block-editor/content.css	4.43 kB
build/block-editor/default-editor-styles-rtl.css	394 B
build/block-editor/default-editor-styles.css	394 B
build/block-editor/style-rtl.css	15.6 kB
build/block-editor/style.css	15.6 kB
build/block-library/blocks/archives/editor-rtl.css	61 B
build/block-library/blocks/archives/editor.css	60 B
build/block-library/blocks/archives/style-rtl.css	90 B
build/block-library/blocks/archives/style.css	90 B
build/block-library/blocks/audio/editor-rtl.css	150 B
build/block-library/blocks/audio/editor.css	150 B
build/block-library/blocks/audio/style-rtl.css	122 B
build/block-library/blocks/audio/style.css	122 B
build/block-library/blocks/audio/theme-rtl.css	126 B
build/block-library/blocks/audio/theme.css	126 B
build/block-library/blocks/avatar/editor-rtl.css	116 B
build/block-library/blocks/avatar/editor.css	116 B
build/block-library/blocks/avatar/style-rtl.css	104 B
build/block-library/blocks/avatar/style.css	104 B
build/block-library/blocks/block/editor-rtl.css	305 B
build/block-library/blocks/block/editor.css	305 B
build/block-library/blocks/button/editor-rtl.css	415 B
build/block-library/blocks/button/editor.css	414 B
build/block-library/blocks/button/style-rtl.css	627 B
build/block-library/blocks/button/style.css	626 B
build/block-library/blocks/buttons/editor-rtl.css	337 B
build/block-library/blocks/buttons/editor.css	337 B
build/block-library/blocks/buttons/style-rtl.css	332 B
build/block-library/blocks/buttons/style.css	332 B
build/block-library/blocks/calendar/style-rtl.css	239 B
build/block-library/blocks/calendar/style.css	239 B
build/block-library/blocks/categories/editor-rtl.css	113 B
build/block-library/blocks/categories/editor.css	112 B
build/block-library/blocks/categories/style-rtl.css	124 B
build/block-library/blocks/categories/style.css	124 B
build/block-library/blocks/code/editor-rtl.css	53 B
build/block-library/blocks/code/editor.css	53 B
build/block-library/blocks/code/style-rtl.css	121 B
build/block-library/blocks/code/style.css	121 B
build/block-library/blocks/code/theme-rtl.css	124 B
build/block-library/blocks/code/theme.css	124 B
build/block-library/blocks/columns/editor-rtl.css	108 B
build/block-library/blocks/columns/editor.css	108 B
build/block-library/blocks/columns/style-rtl.css	421 B
build/block-library/blocks/columns/style.css	421 B
build/block-library/blocks/comment-author-avatar/editor-rtl.css	125 B
build/block-library/blocks/comment-author-avatar/editor.css	125 B
build/block-library/blocks/comment-content/style-rtl.css	92 B
build/block-library/blocks/comment-content/style.css	92 B
build/block-library/blocks/comment-template/style-rtl.css	199 B
build/block-library/blocks/comment-template/style.css	198 B
build/block-library/blocks/comments-pagination-numbers/editor-rtl.css	123 B
build/block-library/blocks/comments-pagination-numbers/editor.css	121 B
build/block-library/blocks/comments-pagination/editor-rtl.css	222 B
build/block-library/blocks/comments-pagination/editor.css	209 B
build/block-library/blocks/comments-pagination/style-rtl.css	235 B
build/block-library/blocks/comments-pagination/style.css	231 B
build/block-library/blocks/comments-title/editor-rtl.css	75 B
build/block-library/blocks/comments-title/editor.css	75 B
build/block-library/blocks/comments/editor-rtl.css	840 B
build/block-library/blocks/comments/editor.css	839 B
build/block-library/blocks/comments/style-rtl.css	637 B
build/block-library/blocks/comments/style.css	636 B
build/block-library/blocks/cover/editor-rtl.css	647 B
build/block-library/blocks/cover/editor.css	650 B
build/block-library/blocks/cover/style-rtl.css	1.69 kB
build/block-library/blocks/cover/style.css	1.68 kB
build/block-library/blocks/details/editor-rtl.css	65 B
build/block-library/blocks/details/editor.css	65 B
build/block-library/blocks/details/style-rtl.css	98 B
build/block-library/blocks/details/style.css	98 B
build/block-library/blocks/embed/editor-rtl.css	322 B
build/block-library/blocks/embed/editor.css	322 B
build/block-library/blocks/embed/style-rtl.css	410 B
build/block-library/blocks/embed/style.css	410 B
build/block-library/blocks/embed/theme-rtl.css	126 B
build/block-library/blocks/embed/theme.css	126 B
build/block-library/blocks/file/editor-rtl.css	316 B
build/block-library/blocks/file/editor.css	316 B
build/block-library/blocks/file/style-rtl.css	280 B
build/block-library/blocks/file/style.css	281 B
build/block-library/blocks/file/view.min.js	324 B
build/block-library/blocks/footnotes/style-rtl.css	201 B
build/block-library/blocks/footnotes/style.css	199 B
build/block-library/blocks/form-input/editor-rtl.css	227 B
build/block-library/blocks/form-input/editor.css	227 B
build/block-library/blocks/form-input/style-rtl.css	343 B
build/block-library/blocks/form-input/style.css	343 B
build/block-library/blocks/form-submission-notification/editor-rtl.css	340 B
build/block-library/blocks/form-submission-notification/editor.css	340 B
build/block-library/blocks/form-submit-button/style-rtl.css	69 B
build/block-library/blocks/form-submit-button/style.css	69 B
build/block-library/blocks/form/view.min.js	471 B
build/block-library/blocks/freeform/editor-rtl.css	2.61 kB
build/block-library/blocks/freeform/editor.css	2.61 kB
build/block-library/blocks/gallery/editor-rtl.css	947 B
build/block-library/blocks/gallery/editor.css	952 B
build/block-library/blocks/gallery/style-rtl.css	1.72 kB
build/block-library/blocks/gallery/style.css	1.72 kB
build/block-library/blocks/gallery/theme-rtl.css	108 B
build/block-library/blocks/gallery/theme.css	108 B
build/block-library/blocks/group/editor-rtl.css	647 B
build/block-library/blocks/group/editor.css	647 B
build/block-library/blocks/group/style-rtl.css	57 B
build/block-library/blocks/group/style.css	57 B
build/block-library/blocks/group/theme-rtl.css	78 B
build/block-library/blocks/group/theme.css	78 B
build/block-library/blocks/heading/style-rtl.css	189 B
build/block-library/blocks/heading/style.css	189 B
build/block-library/blocks/html/editor-rtl.css	336 B
build/block-library/blocks/html/editor.css	337 B
build/block-library/blocks/image/editor-rtl.css	878 B
build/block-library/blocks/image/editor.css	878 B
build/block-library/blocks/image/style-rtl.css	1.6 kB
build/block-library/blocks/image/style.css	1.59 kB
build/block-library/blocks/image/theme-rtl.css	126 B
build/block-library/blocks/image/theme.css	126 B
build/block-library/blocks/image/view.min.js	1.54 kB
build/block-library/blocks/latest-comments/style-rtl.css	357 B
build/block-library/blocks/latest-comments/style.css	357 B
build/block-library/blocks/latest-posts/editor-rtl.css	213 B
build/block-library/blocks/latest-posts/editor.css	212 B
build/block-library/blocks/latest-posts/style-rtl.css	478 B
build/block-library/blocks/latest-posts/style.css	478 B
build/block-library/blocks/list/style-rtl.css	88 B
build/block-library/blocks/list/style.css	88 B
build/block-library/blocks/media-text/editor-rtl.css	306 B
build/block-library/blocks/media-text/editor.css	305 B
build/block-library/blocks/media-text/style-rtl.css	505 B
build/block-library/blocks/media-text/style.css	503 B
build/block-library/blocks/more/editor-rtl.css	431 B
build/block-library/blocks/more/editor.css	431 B
build/block-library/blocks/navigation-link/editor-rtl.css	668 B
build/block-library/blocks/navigation-link/editor.css	669 B
build/block-library/blocks/navigation-link/style-rtl.css	259 B
build/block-library/blocks/navigation-link/style.css	257 B
build/block-library/blocks/navigation-submenu/editor-rtl.css	296 B
build/block-library/blocks/navigation-submenu/editor.css	295 B
build/block-library/blocks/navigation/editor-rtl.css	2.26 kB
build/block-library/blocks/navigation/editor.css	2.26 kB
build/block-library/blocks/navigation/style-rtl.css	2.26 kB
build/block-library/blocks/navigation/style.css	2.25 kB
build/block-library/blocks/navigation/view.min.js	1.02 kB
build/block-library/blocks/nextpage/editor-rtl.css	395 B
build/block-library/blocks/nextpage/editor.css	395 B
build/block-library/blocks/page-list/editor-rtl.css	377 B
build/block-library/blocks/page-list/editor.css	377 B
build/block-library/blocks/page-list/style-rtl.css	175 B
build/block-library/blocks/page-list/style.css	175 B
build/block-library/blocks/paragraph/editor-rtl.css	235 B
build/block-library/blocks/paragraph/editor.css	235 B
build/block-library/blocks/paragraph/style-rtl.css	335 B
build/block-library/blocks/paragraph/style.css	335 B
build/block-library/blocks/post-author/style-rtl.css	175 B
build/block-library/blocks/post-author/style.css	176 B
build/block-library/blocks/post-comments-form/editor-rtl.css	96 B
build/block-library/blocks/post-comments-form/editor.css	96 B
build/block-library/blocks/post-comments-form/style-rtl.css	508 B
build/block-library/blocks/post-comments-form/style.css	508 B
build/block-library/blocks/post-content/editor-rtl.css	74 B
build/block-library/blocks/post-content/editor.css	74 B
build/block-library/blocks/post-date/style-rtl.css	61 B
build/block-library/blocks/post-date/style.css	61 B
build/block-library/blocks/post-excerpt/editor-rtl.css	71 B
build/block-library/blocks/post-excerpt/editor.css	71 B
build/block-library/blocks/post-excerpt/style-rtl.css	141 B
build/block-library/blocks/post-excerpt/style.css	141 B
build/block-library/blocks/post-featured-image/editor-rtl.css	666 B
build/block-library/blocks/post-featured-image/editor.css	662 B
build/block-library/blocks/post-featured-image/style-rtl.css	342 B
build/block-library/blocks/post-featured-image/style.css	342 B
build/block-library/blocks/post-navigation-link/style-rtl.css	215 B
build/block-library/blocks/post-navigation-link/style.css	214 B
build/block-library/blocks/post-template/editor-rtl.css	99 B
build/block-library/blocks/post-template/editor.css	98 B
build/block-library/blocks/post-template/style-rtl.css	409 B
build/block-library/blocks/post-template/style.css	408 B
build/block-library/blocks/post-terms/style-rtl.css	96 B
build/block-library/blocks/post-terms/style.css	96 B
build/block-library/blocks/post-time-to-read/style-rtl.css	69 B
build/block-library/blocks/post-time-to-read/style.css	69 B
build/block-library/blocks/post-title/style-rtl.css	100 B
build/block-library/blocks/post-title/style.css	100 B
build/block-library/blocks/preformatted/style-rtl.css	125 B
build/block-library/blocks/preformatted/style.css	125 B
build/block-library/blocks/pullquote/editor-rtl.css	135 B
build/block-library/blocks/pullquote/editor.css	135 B
build/block-library/blocks/pullquote/style-rtl.css	354 B
build/block-library/blocks/pullquote/style.css	354 B
build/block-library/blocks/pullquote/theme-rtl.css	168 B
build/block-library/blocks/pullquote/theme.css	168 B
build/block-library/blocks/query-pagination-numbers/editor-rtl.css	122 B
build/block-library/blocks/query-pagination-numbers/editor.css	121 B
build/block-library/blocks/query-pagination/editor-rtl.css	221 B
build/block-library/blocks/query-pagination/editor.css	211 B
build/block-library/blocks/query-pagination/style-rtl.css	288 B
build/block-library/blocks/query-pagination/style.css	284 B
build/block-library/blocks/query-title/style-rtl.css	63 B
build/block-library/blocks/query-title/style.css	63 B
build/block-library/blocks/query/editor-rtl.css	486 B
build/block-library/blocks/query/editor.css	486 B
build/block-library/blocks/query/view.min.js	958 B
build/block-library/blocks/quote/style-rtl.css	237 B
build/block-library/blocks/quote/style.css	237 B
build/block-library/blocks/quote/theme-rtl.css	223 B
build/block-library/blocks/quote/theme.css	226 B
build/block-library/blocks/read-more/style-rtl.css	140 B
build/block-library/blocks/read-more/style.css	140 B
build/block-library/blocks/rss/editor-rtl.css	149 B
build/block-library/blocks/rss/editor.css	149 B
build/block-library/blocks/rss/style-rtl.css	289 B
build/block-library/blocks/rss/style.css	288 B
build/block-library/blocks/search/editor-rtl.css	184 B
build/block-library/blocks/search/editor.css	184 B
build/block-library/blocks/search/style-rtl.css	629 B
build/block-library/blocks/search/style.css	628 B
build/block-library/blocks/search/theme-rtl.css	114 B
build/block-library/blocks/search/theme.css	114 B
build/block-library/blocks/search/view.min.js	478 B
build/block-library/blocks/separator/editor-rtl.css	146 B
build/block-library/blocks/separator/editor.css	146 B
build/block-library/blocks/separator/style-rtl.css	229 B
build/block-library/blocks/separator/style.css	229 B
build/block-library/blocks/separator/theme-rtl.css	194 B
build/block-library/blocks/separator/theme.css	194 B
build/block-library/blocks/shortcode/editor-rtl.css	323 B
build/block-library/blocks/shortcode/editor.css	323 B
build/block-library/blocks/site-logo/editor-rtl.css	754 B
build/block-library/blocks/site-logo/editor.css	754 B
build/block-library/blocks/site-logo/style-rtl.css	204 B
build/block-library/blocks/site-logo/style.css	204 B
build/block-library/blocks/site-tagline/editor-rtl.css	86 B
build/block-library/blocks/site-tagline/editor.css	86 B
build/block-library/blocks/site-title/editor-rtl.css	116 B
build/block-library/blocks/site-title/editor.css	116 B
build/block-library/blocks/site-title/style-rtl.css	57 B
build/block-library/blocks/site-title/style.css	57 B
build/block-library/blocks/social-link/editor-rtl.css	184 B
build/block-library/blocks/social-link/editor.css	184 B
build/block-library/blocks/social-links/editor-rtl.css	682 B
build/block-library/blocks/social-links/editor.css	681 B
build/block-library/blocks/social-links/style-rtl.css	1.48 kB
build/block-library/blocks/social-links/style.css	1.48 kB
build/block-library/blocks/spacer/editor-rtl.css	350 B
build/block-library/blocks/spacer/editor.css	350 B
build/block-library/blocks/spacer/style-rtl.css	48 B
build/block-library/blocks/spacer/style.css	48 B
build/block-library/blocks/table/editor-rtl.css	395 B
build/block-library/blocks/table/editor.css	395 B
build/block-library/blocks/table/style-rtl.css	639 B
build/block-library/blocks/table/style.css	639 B
build/block-library/blocks/table/theme-rtl.css	146 B
build/block-library/blocks/table/theme.css	146 B
build/block-library/blocks/tag-cloud/style-rtl.css	251 B
build/block-library/blocks/tag-cloud/style.css	253 B
build/block-library/blocks/template-part/editor-rtl.css	403 B
build/block-library/blocks/template-part/editor.css	403 B
build/block-library/blocks/template-part/theme-rtl.css	101 B
build/block-library/blocks/template-part/theme.css	101 B
build/block-library/blocks/term-description/style-rtl.css	111 B
build/block-library/blocks/term-description/style.css	111 B
build/block-library/blocks/text-columns/editor-rtl.css	95 B
build/block-library/blocks/text-columns/editor.css	95 B
build/block-library/blocks/text-columns/style-rtl.css	166 B
build/block-library/blocks/text-columns/style.css	166 B
build/block-library/blocks/verse/style-rtl.css	99 B
build/block-library/blocks/verse/style.css	99 B
build/block-library/blocks/video/editor-rtl.css	552 B
build/block-library/blocks/video/editor.css	555 B
build/block-library/blocks/video/style-rtl.css	185 B
build/block-library/blocks/video/style.css	185 B
build/block-library/blocks/video/theme-rtl.css	126 B
build/block-library/blocks/video/theme.css	126 B
build/block-library/classic-rtl.css	179 B
build/block-library/classic.css	179 B
build/block-library/common-rtl.css	1.11 kB
build/block-library/common.css	1.11 kB
build/block-library/editor-elements-rtl.css	75 B
build/block-library/editor-elements.css	75 B
build/block-library/editor-rtl.css	12.4 kB
build/block-library/editor.css	12.4 kB
build/block-library/elements-rtl.css	54 B
build/block-library/elements.css	54 B
build/block-library/index.min.js	218 kB
build/block-library/reset-rtl.css	472 B
build/block-library/reset.css	472 B
build/block-library/style-rtl.css	14.8 kB
build/block-library/style.css	14.8 kB
build/block-library/theme-rtl.css	688 B
build/block-library/theme.css	693 B
build/block-serialization-default-parser/index.min.js	1.12 kB
build/block-serialization-spec-parser/index.min.js	2.87 kB
build/blocks/index.min.js	51.8 kB
build/commands/index.min.js	15.6 kB
build/commands/style-rtl.css	935 B
build/commands/style.css	930 B
build/components/index.min.js	224 kB
build/components/style-rtl.css	11.8 kB
build/components/style.css	11.9 kB
build/compose/index.min.js	12.6 kB
build/core-commands/index.min.js	2.77 kB
build/core-data/index.min.js	72.8 kB
build/customize-widgets/index.min.js	11.2 kB
build/customize-widgets/style-rtl.css	1.36 kB
build/customize-widgets/style.css	1.36 kB
build/data-controls/index.min.js	640 B
build/data/index.min.js	8.95 kB
build/date/index.min.js	17.9 kB
build/deprecated/index.min.js	451 B
build/dom-ready/index.min.js	324 B
build/dom/index.min.js	4.65 kB
build/edit-post/classic-rtl.css	558 B
build/edit-post/classic.css	558 B
build/edit-post/index.min.js	24.2 kB
build/edit-post/style-rtl.css	5.58 kB
build/edit-post/style.css	5.57 kB
build/edit-site/index.min.js	218 kB
build/edit-site/style-rtl.css	15 kB
build/edit-site/style.css	15 kB
build/edit-widgets/index.min.js	17.3 kB
build/edit-widgets/style-rtl.css	4.17 kB
build/edit-widgets/style.css	4.16 kB
build/editor/index.min.js	64 kB
build/editor/style-rtl.css	5.36 kB
build/editor/style.css	5.35 kB
build/element/index.min.js	4.83 kB
build/escape-html/index.min.js	537 B
build/format-library/index.min.js	8.03 kB
build/format-library/style-rtl.css	492 B
build/format-library/style.css	490 B
build/hooks/index.min.js	1.55 kB
build/html-entities/index.min.js	448 B
build/i18n/index.min.js	3.58 kB
build/interactivity/file.min.js	447 B
build/interactivity/image.min.js	1.67 kB
build/interactivity/index.min.js	13 kB
build/interactivity/navigation.min.js	1.15 kB
build/interactivity/query.min.js	740 B
build/interactivity/router.min.js	1.36 kB
build/interactivity/search.min.js	618 B
build/is-shallow-equal/index.min.js	527 B
build/keyboard-shortcuts/index.min.js	1.74 kB
build/keycodes/index.min.js	1.46 kB
build/list-reusable-blocks/index.min.js	2.11 kB
build/list-reusable-blocks/style-rtl.css	851 B
build/list-reusable-blocks/style.css	849 B
build/media-utils/index.min.js	2.92 kB
build/modules/importmap-polyfill.min.js	12.2 kB
build/notices/index.min.js	948 B
build/nux/index.min.js	2 kB
build/nux/style-rtl.css	747 B
build/nux/style.css	742 B
build/patterns/index.min.js	5.73 kB
build/patterns/style-rtl.css	553 B
build/patterns/style.css	552 B
build/plugins/index.min.js	1.8 kB
build/preferences-persistence/index.min.js	2.05 kB
build/preferences/index.min.js	2.81 kB
build/preferences/style-rtl.css	710 B
build/preferences/style.css	712 B
build/primitives/index.min.js	975 B
build/priority-queue/index.min.js	1.52 kB
build/private-apis/index.min.js	1 kB
build/react-i18n/index.min.js	623 B
build/react-refresh-entry/index.min.js	9.47 kB
build/react-refresh-runtime/index.min.js	6.78 kB
build/redux-routine/index.min.js	2.7 kB
build/reusable-blocks/index.min.js	2.73 kB
build/reusable-blocks/style-rtl.css	256 B
build/reusable-blocks/style.css	256 B
build/rich-text/index.min.js	10.5 kB
build/router/index.min.js	1.79 kB
build/server-side-render/index.min.js	1.96 kB
build/shortcode/index.min.js	1.39 kB
build/style-engine/index.min.js	2.1 kB
build/token-list/index.min.js	582 B
build/url/index.min.js	3.72 kB
build/vendors/inert-polyfill.min.js	2.48 kB
build/vendors/react-dom.min.js	41.7 kB
build/vendors/react.min.js	4.02 kB
build/viewport/index.min.js	957 B
build/warning/index.min.js	249 B
build/widgets/index.min.js	7.21 kB
build/widgets/style-rtl.css	1.17 kB
build/widgets/style.css	1.17 kB
build/wordcount/index.min.js	1.02 kB

_{compressed-size-action}

[github-actions[bot]]

Flaky tests detected in da5d3977b02e8881ddf616c34008a770d37ddf19. 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/8015701363 📝 Reported issues:

• #48033 in /test/e2e/specs/editor/blocks/navigation.spec.js

[github-actions[bot]]

This pull request changed or added PHP files in previous commits, but none have been detected in the latest commit.

Thank you! :heart:

[tellthemachines]

Marking this ready for review to get feedback on the approach; will add tests once we're agreed on it.

[github-actions[bot]]

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 <[email protected]>
Co-authored-by: ramonjd <[email protected]>
Co-authored-by: andrewserong <[email protected]>
Co-authored-by: jameskoster <[email protected]>
Co-authored-by: SaxonF <[email protected]>
Co-authored-by: youknowriad <[email protected]>

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

[tellthemachines]

Thanks for reviewing and testing folks!

wondering if layout.php will ever benefit from a code refactor/abstraction

Probably! There's some repetition in the block gap logic.

When I go to add a Cover block, it throws an error for me

Cover block strikes again 👀 I'll look into it!

When I add a Paragraph with a background colour to a constrained Group block and give it a "Fixed" width, it can extend beyond the edge of the viewport / outside of the constrained area

Yes! That's what it's supposed to do. There were complaints about the "Fixed" option in the flex child controls not being really fixed, so this time fixed is 100% not trying to do anything smart behind the scenes. "Max width" (and "Max height") are basically the same as the previous fixed-not-really-fixed option; I guess we could add them to constrained/flow layouts too?

When adding an Image block to a constrained Group, the height controls don't appear to work as expected. Because of the potential for rule / styling conflicts, I wonder if it'd be worth it to make the controls opt-in?

Yeah that's an interesting problem. It's an existing issue when adding fixed height to an Image block inside a Stack block with the flex child controls, and I'm tempted to address it separately with a fix in the actual Image block, somewhat like we did for Spacer in #49362.

I don't think making the controls opt-in would be viable because we want them to ideally work for all blocks; it's preferable to try and unify controls where possible.

if a user lays content out in such a way where the max width looks good on desktop, what will happen in narrower viewports?

If I built this correctly 😅 there should never be an overflow for max-width because it always adjusts to the container width.

One other thought in the back of my mind: how might the width / height rules play with the new aspectRatio support? If width / height is updated, would we want to clear out any aspectRatio values, or vice versa?

Ah yes, good point, we'll have to do something about that! I imagine something along the lines of the current relationship between aspectRatio and Min height, where setting one unsets the other?

[tellthemachines]

Ok Cover block issue fixed!

[tellthemachines]

"Max width" (and "Max height") are basically the same as the previous fixed-not-really-fixed option; I guess we could add them to constrained/flow layouts too?

Ok so I've added the "Max width" option to all vertical layouts. The slight issue here is that currently, setting it on a child of a constrained block gets overridden by the default layout max-width 😅

My attempts to reduce layout CSS specificity over in #57841 were not entirely successful; it's unlikely that the generic body .is-layout-constrained > :where(:not(.alignleft):not(.alignright):not(.alignfull)) can be reduced further. I guess we have two options here: duplicate the .wp-container-content-x selector, or add an !important to the end of the max-width rule.

(I also realised in testing that Fixed widths aren't working properly in constrained layouts either so might need a max-width: none in there, which would also require some extra specificity)

It's not great, but I'm inclined towards !important because that is limited to the specific property, whereas duplicating the selector will apply to all child properties.

[tellthemachines]

it's unlikely that the generic body .is-layout-constrained > :where(:not(.alignleft):not(.alignright):not(.alignfull)) can be reduced further.

Just thinking a bit more about this and we might be able to remove the body part of the layout selector, in which case the max-width inside .wp-container-content-x would override it because it's added further down in the document head.

This inclines me further towards a temporary addition of !important to just the max-width, which we can hopefully remove later once the layout specificity is sorted.

[andrewserong]

Yes! That's what it's supposed to do. There were complaints about the "Fixed" option in the flex child controls not being really fixed, so this time fixed is 100% not trying to do anything smart behind the scenes.

Ah, very interesting! This is quite likely my own personal preference, but to me it makes the controls harder to use if they don't include automatically handling things gracefully reflowing on smaller screens. My expectation when I was playing with it was that I'd be able to break out of the constrained layout (so, go wider than the column I'm in), but it'd still be reduced down to the viewport width, otherwise it felt like it'd be easy to break layouts on narrower viewports. I think most of the time folks won't want to accidentally create horizontally scrolling content. Max Width gets us pretty close to that, but while using the current state of the controls, I found myself wanting something that's somewhere between Max Width, Fill, and Fixed. In any case, I'm not a designer, so it'd be great to see what others think, and what covers the majority use case of folks reaching for these controls.

"Max width" (and "Max height") are basically the same as the previous fixed-not-really-fixed option; I guess we could add them to constrained/flow layouts too?

They get most of the way there, so sounds good to me!

I don't think making the controls opt-in would be viable because we want them to ideally work for all blocks; it's preferable to try and unify controls where possible.

Ah, I see, because it's the parent that sets "allowSizingOnChildren"? In that case, perhaps an opt-out if there are blocks that really need it?

If I built this correctly 😅 there should never be an overflow for max-width because it always adjusts to the container width.

My comment wasn't worded very well, but I was actually thinking about the height overflowing. There's a couple of different ways it can happen at the moment, but here's a simple example when setting a Fixed height, where it looks good at a desktop size, but overflows in narrower viewports:

Desktop	Narrower

It's similarly possible to wind up with overflowing content with a child of a Row block when setting a max height:

From memory, I think there were some similar conversations with the aspect ratio controls. The way that the aspect ratio wound up working in the end is that if the content is longer than the aspect ratio, then the size of the block grows with the content, so we could avoid the scrollbar or overflowing content problem. Not sure if that's really applicable here, though. I think @jasmussen or @jameskoster might have mentioned the idea of exploring controls for overflowing content one day 🤔

I imagine something along the lines of the current relationship between aspectRatio and Min height, where setting one unsets the other?

Unsetting an aspect ratio value when one of these dimensions values is set sounds good to me!

One other thing I noticed while re-testing, is that if I enter a Width and Height, the ToolsPanel menu only sees a change to Width and not to Height:

[jameskoster]

For me the main question is about user expectations regarding the behavior of elements with fixed heights. Would users anticipate overflowing, clipping, or scrolling? My inclination is to implement one of these behaviors now and allow customization through overflow controls later.

[SaxonF]

For me the main question is about user expectations regarding the behavior of elements with fixed heights. Would users anticipate overflowing, clipping, or scrolling? My inclination is to implement one of these behaviors now and allow customization through overflow controls later.

I would lean towards hidden by default as it seems the safer starting point. What do you think @jameskoster ?

[tellthemachines]

One other thing I noticed while re-testing, is that if I enter a Width and Height, the ToolsPanel menu only sees a change to Width and not to Height:

Oh bugger, I always forget about the tools panel resets 😬 This'll be interesting, because ToolsPanelItem only supports resetting one control at a time 😅 so I guess either we dump a bunch of logic to determine which control to reset in Dimensions, or we move everything into ChildLayoutControl and let it render the ToolsPanelItem itself. I'll have a play and see what works best!

[tellthemachines]

I'll have a play and see what works best!

Actually, I think we'll have to let ChildLayoutControl absorb the rendering of ToolsPanelItem because we'll need a ToolsPanelItem for each of the Width and Height controls.

[tellthemachines]

Ok ToolsPanel resets are now split (except for Grid column and row, but that's probably better done as a separate task if we feel it's needed)

Remaining issues are:

• What to do about Height/Max height when content overflows (tentatively going with hiding the overflow for now - this has the advantage of being consistent with aspect ratio behaviour as of #59388)
• What to do about Aspect ratio: currently we have two implementations of Aspect ratio - the Image block-specific one and the block support.
  • The Image block implementation resets aspect ratio when both width and height are defined on the block, otherwise if only one is set, it respects it and preserves the aspect ratio. I kinda like this because it's in line with how CSS behaves out of the box.
  • The block support resets when min-height is added (and vice-versa) because min-height combined with aspect-ratio can have unexpected results, but height, max-height, width and max-width are more predictable so perhaps we can make them behave like the Image block?

In that case, perhaps an opt-out if there are blocks that really need it?

I'm reluctant to add a new API until we know for sure it's necessary; to address the Image block issue we could follow up with another PR to unify these controls with the Image block ones. I don't think it's hugely problematic to leave the controls enabled for it in the meantime; we already have flex child controls being used on Image blocks (so disabling would sort of break back compat there too) and for the most part the flow/constrained addition will work well with existing align wide/full Image support.

It's also worth mentioning that I'm not worried about custom blocks here, because most of them strip out the whole sidebar styles/settings and replace them with their own 😅 and the ones that don't usually work well with core block supports because they already use some or all of the supports.

Fixed/max widths and heights are the only settings that don't always work properly, particularly when blocks already set width and height and/or have multiple wrappers. It could be worth looking at a skipSerialization option for these scenarios (not sure where it might best be added though - under dimensions?). From my testing Image is the flakiest one; then there are cases like Audio and Table where adding a fixed height just increases the space under the blocks. All of these could potentially be addressed case-by-case with adjustments so the controls work.

We could also not add fixed/max widths and heights to flow and constrained children for now (we should maintain them for flex because they're partially supported already) but we'll be missing (once again) the opportunity to add functionality that has been requested over and over, which seems a shame.

[jameskoster]

I would lean towards hidden by default as it seems the safer starting point

Agreed. I'm struggling to decide on scrolling though. For text you'd probably expect scrolling, but more decorative sections (e.g. image in a container) you wouldn't want scrolling.

[youknowriad]

Hi There! Thanks for working on these two controls. I think these are great additions that will allow new sets of designs. These tools also offer new opportunities for consolidations and improvements for our existing APIs/tools.

Note that some initial thoughts about this have been shared in #28356

A summary of some of the important points that I think we should consider:

• Should we have a dedicated "block support" key for width and heights?
• Should we make these opt-in by using the appearanceTools flag (like we do for most new block supports)?
• For width, I believe we should explore having "width presets" which combined with a "max width" control would allow us to address this issue #27629 and bring some clarity (separating wide/full which are in fact max widths from alignments left, right, center)

[tellthemachines]

Thanks for the feedback @youknowriad! Those are some interesting points, and I have a lot of thoughts about them, so please bear with me while I think out loud a bit 😅

• Should we have a dedicated "block support" key for width and heights?

I'm not sure! The only reason I can think of that dedicated width and height block supports would be useful is for specific blocks to opt out of them if necessary. #43241 is good evidence for questioning the initial assumption around block supports being opt-in: in the end, we do want most of them to be usable with most blocks, so it would be far easier to have a system that allows for exceptions than one that forces us to add everything explicitly to every single block.

I guess the major point against is incompatibility with the existing implementation: width and height controls are already available for children of Row/Stack and Navigation blocks (width or height, depending on layout orientation), with the parent block opting in to the controls for all its children. This approach makes sense for the flex layout type, because blocks inside that layout need to be adjusted in relation to each other. The same applies to the column and row span controls for grid children added in #58539, which for practical purposes replace width and height controls for those blocks (width and height for grid children don't make much sense, because they are already constrained by the grid's column and row rules).

Another thing to consider is that calculating the CSS for different width and height settings is also dependent on layout: making a block fixed or max-width inside a flex container is different to a flow container. Presets like content and wide width could kinda be made to work in a flex container (default flex shrinking behaviour complicates it a lot) but they would require different styles to do so.

• Should we make these opt-in by using the appearanceTools flag (like we do for most new block supports)?

We might have missed the boat on that one: flex layout was never put under appearanceTools so it could be available on all classic themes. When the flex child controls were implemented (as well as the grid layout later on) the same logic was followed.

• For width, I believe we should explore having "width presets"

That would be great! Separating "wide" and "full" from alignments won't be trivial though, due to back compat: even if we did decide that all core blocks should have all the alignments (which I'm totally in favour of 😄), we should still respect any filters applied to registerBlockType that change the align support for the block.

I think this should probably be a separate task from this PR. I don't think anything in this PR actually prevents that exploration? Assuming that we will have to preserve back compat for legacy align attributes, that is.

[youknowriad]

We might have missed the boat on that one: flex layout was never put under appearanceTools so it could be available on all classic themes. When the flex child controls were implemented (as well as the grid layout later on) the same logic was followed.

For me width/height are different from layout. I can understand why layout would be made available automatically for all themes, it's not really a customization/appearance tools but I feel it's the case for height and width this is the reason why maybe a dedicated opt-in could make sense (that would be enabled by default with appearanceTools)

That would be great! Separating "wide" and "full" from alignments won't be trivial though, due to back compat: even if we did decide that all core blocks should have all the alignments (which I'm totally in favour of 😄), we should still respect any filters applied to registerBlockType that change the align support for the block.

I agree it's separate and I agree back compat would be complex, I feel this is one of these things that we should first consider an experiment and I'm not sure a "migration" is possible to be honest, more like for new versions: hide these from alignments in favor of a maxWidth control. The relationship with this PR is that we might want to introduce width presets that work both for this PR and these alignments, which means I'm not sure we should support "wide", and "default" should be options to start with in this PR because they might create backward compatibility issues when we introduce "width presets".

[tellthemachines]

For me width/height are different from layout. I can understand why layout would be made available automatically for all themes, it's not really a customization/appearance tools but I feel it's the case for height and width this is the reason why maybe a dedicated opt-in could make sense

Width and height need to know about layout, though that wouldn't be a blocker to making them a separate support (just like block spacing). The blocker is that the width/height control for flex children is already available on classic themes that don't opt in to appearance tools, so changing that would break back compat.

We could maybe make width/height for flow and constrained children an appearance tools opt in, but if it's already universally available for flex children I'm not sure there's much point to it 😅

[tellthemachines]

The relationship with this PR is that we might want to introduce width presets that work both for this PR and these alignments, which means I'm not sure we should support "wide", and "default" should be options to start with in this PR because they might create backward compatibility issues when we introduce "width presets

I've updated the PR so that "default" doesn't show as a width option unless either the theme explicitly declares contentSize, or the parent block sets a custom contentSize. I applied the same logic to wideSize.

It should be fairly easy to add any custom width presets the theme defines in the future to this list so they appear as options in the dropdown. Whether we go with just allowing to add other options directly under the layout setting like

layout: {
	"contentSize": "600px",
	"wideSize": "900px",
	"narrowSize": "300px"
}

or we define a new key like

"layout": {
	"widthPresets": {
		"contentSize": "600px",
		…
	}
}

we'll probably need to keep "contentSize" as the default content size to be used in constrained layouts. Thinking that in the future we may want to use templates from any theme in any other theme, it will be helpful to have a universal content size variable for compatibility.

In regard to classic themes, I've been testing these controls in a few of them, and they don't always work as expected. Classic themes usually define content widths themselves, and some of them (e.g. TwentyTwenty) do so with enough specificity to override the output from these controls.

Because we won't be able to make the controls work consistently across classic themes, I'm inclining towards hiding them altogether (like we always hide the flow/constrained layout toggle, even if the theme does support appearance-tools).

[tellthemachines]

Update: I've hidden the width and height controls in classic themes for children of flow/constrained layouts.

[youknowriad]

Width and height need to know about layout, though that wouldn't be a blocker to making them a separate support

While I can see that width might not apply as you expect in some layouts, I don't really understand why these are specific to layout. A width 100px could work for either something with "flow", or something within horizontal flex. A height 100px could work for flow, vertical flex, or even grid right? It seems fine if it's ignored in some layouts?

layout: { "contentSize": "600px", "wideSize": "900px", "narrowSize": "300px" }

That also doesn't sound great to be honest, I really don't think we should conflate "contentSize", "wideSize"... with widths presets. I feel we should consider these as legacy from the start and instead just treat width presets as any other presents:

const features = {
	color: {
		palette: {
			theme: [
				{ name: 'red', color: '#f00', slug: 'red' },
				{ name: 'white', color: '#fff', slug: 'white' },
				{ name: 'blue', color: '#00f', slug: 'blue' },
			],
		},
	},
        dimensions: {
                 width: true,
                 height: true,
                 widthPalette: {
			theme: [
                                { name: 'Wide', value: '800px', slug: 'wide' },
                                { name: 'Content', value: '600px', slug: 'content' },
                        ]
                 }
        }
        layout: {
                contentSize: 'var:preset|width|content'
        }
};

[SaxonF]

@youknowriad from a UI perspective though we have various controls that reference content/wide (eg align) but overlap with the idea of width. If I select a width value from presets that contentWidth uses, is that the same as setting align?

[youknowriad]

@youknowriad from a UI perspective though we have various controls that reference content/wide (eg align) but overlap with the idea of width. If I select a width value from presets that contentWidth uses, is that the same as setting align?

No, the presets are just there to be reused in one or multiple places (like we do for colors for instances). So we could use them for "align" (which is basically maxWidth support) and we can use them for the new "width" introduced in this PR.

[tellthemachines]

While I can see that width might not apply as you expect in some layouts, I don't really understand why these are specific to layout. A width 100px could work for either something with "flow", or something within horizontal flex.

We need different CSS to apply width in flex and block display types. So for instance, width: 100px won't work as expected in flex; we also need to add flex-shrink: 0 to make sure the width stays fixed. Widths inside a grid type can easily overflow their column and look broken, which is why I opted to not allow them for now. "Fill" width in a horizontal flex layout requires flex-grow: 1 because it's meant to fill the remaining container space instead of stretching to 100% width. "Fill" as an option for height only works in flex layouts.

Even from a user perspective, adjusting width and height for a block will usually take into account the parent and the sibling blocks. It's making a block stretch to the full width of its container, or making two or three blocks in a Row have the same height, or two blocks side by side have the same width. I think semantically these controls naturally fit in with layout.

[youknowriad]

We need different CSS to apply width in flex and block display types. So for instance, width: 100px won't work as expected in flex; we also need to add flex-shrink: 0 to make sure the width stays fixed.

Shouldn't we be adding flex-shrink automatically to all flex children? I can't think of cases where it's helpful to allow shrinking?

Regardless, there's already a precent for block supports that have "small" dependencies to layout but are not entirely dependent on layout: fluid typography.

Widths inside a grid type can easily overflow their column and look broken,

I'm not sure how prescriptive we should be, I've seen people ask for a possibility to do this (overflowing columns)

"Fill" width in a horizontal flex layout requires flex-grow: 1 because it's meant to fill the remaining container space instead of stretching to 100% width.

It's not entirely clear whether we should mix this one (flex-grow) with "width" or whether it should be its own checkbox. If it's a checkbox it's separate from width support (in fact for vertical flex, I believe its behavior is to grow the height) but even if we keep it within the width, as I said above, a small dependency to layout is fine.

[tellthemachines]

Shouldn't we be adding flex-shrink automatically to all flex children? I can't think of cases where it's helpful to allow shrinking?

You'd think so! But after initially implementing "Fixed" widths for flex with no shrinking, some folks thought it wasn't a good idea, so I reverted it in #46139. Essentially, what we implemented there was a "Max width", not a "Fixed" width at all.

I do think that there's a need for both, but the current controls are suboptimal because they do one thing (max width) and call it the other (fixed width). Really, this PR was intended more as a refinement of those controls.

The extension of these capabilities to children of flow/constrained layouts makes sense within the context of #42385, as one of the goals is to be able to switch seamlessly between flow, constrained and vertical flex layouts (so they should all have similar controls). The other side of that is presenting all the layout-related tools in one section. It makes no sense to have block gap, width, height etc., in a separate "Dimensions" panel because usually these settings are adjusted in relation to each other.

I'm not sure how prescriptive we should be, I've seen people ask for a possibility to do this (overflowing columns)

I'd love to see some specific use-cases! I suspect if what folks want is to overlap columns, the column/row start controls experimentally added in #59483 would be the best way of doing that.

It's not entirely clear whether we should mix this one (flex-grow) with "width" or whether it should be its own checkbox.

I'm going to trust @SaxonF on this one 😄 For users, conceptually separating "width" from "expand to fill the empty space" might not make much sense.

[SaxonF]

It's not entirely clear whether we should mix this one (flex-grow) with "width" or whether it should be its own checkbox.

One of the benefits of treating this as a width setting is that its consistent with other design tools like Figma, which is important for making designers feel at home. I'd like to start here and pull out into its own thing if we get that feedback consistently.

[andrewserong]

I do think that there's a need for both, but the current controls are suboptimal because they do one thing (max width) and call it the other (fixed width). Really, this PR was intended more as a refinement of those controls.

Would it be helpful to potentially further divide up this PR up into separate pieces? E.g. one PR that only looks at the redesigned controls for flex but keeps the styling output the same? (I.e. switches to the select dropdown, with Fixed renamed to Max Width)

There's lots of fascinating ideas, questions and decisions with these controls, and I wondered if doing something like that might help sidestep the question of how flow/constrained width and height controls should work, while still progressing the goal of redesigning them. Or is it better for them to be considered together as a whole?