Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add Layout controls to children of Flex layout blocks #45364

Merged
merged 21 commits into from
Nov 25, 2022

Conversation

tellthemachines
Copy link
Contributor

@tellthemachines tellthemachines commented Oct 28, 2022

Why?

Closes #44467

  • Adds a "width" or a "height" control in the Dimensions panel of children of Row/Stack blocks (width for Row, height for Stack);
  • The section contains a toggle with three options: Fit, Fill and Fixed.
  • If Fixed is selected, an input is also shown, where a fixed size for the block can be set.

Follow up tasks (not within the scop of this PR):

  • With vertical orientation, "Fill" won't work unless the parent container has a fixed height. Given Add a minHeight block support under dimensions #45300, we are now able to do this! But it might be good to add a warning or additional info on how it works.
  • Should we disallow "min-height" in blocks that get the "height" control due to being Stack children?
  • Revisit safecss_filter_attr to allow box-sizing rules to be output.
  • look into removing styles once a block is moved out of its flex parent (or parent is transformed into a non-flex group).

How?

  • Adds an optional allowSizingOnChildren layout attribute to enable width/height controls on children of flex blocks.
  • This attribute is only added to Row and Stack group variations for now.
  • Adds an __unstableParentLayout prop to BlockListBlock, which is used to decide whether those child controls should be output or not, based on the existence of allowSizingOnChildren and a flex type layout.

Testing Instructions

  1. Add a Row block to a post and add some child blocks in it;
  2. Check that width controls renders in Dimensions in the block sidebar for the child blocks;
  3. Check that setting "fill" and "fixed" sizes works for child blocks.
  4. Repeat test with a Stack block, which should show the "height" control on its children;
  5. In order for "fill" to work for Stack children, define a min-height on the Stack block (also under Dimensions).

Screenshots or screencast

Screenshot 2022-11-24 at 10 03 10 am

@codesandbox
Copy link

codesandbox bot commented Oct 28, 2022

CodeSandbox logoCodeSandbox logo  Open in CodeSandbox Web Editor | VS Code | VS Code Insiders

@tellthemachines tellthemachines added the [Feature] Layout Layout block support, its UI controls, and style output. label Oct 28, 2022
@tellthemachines tellthemachines self-assigned this Oct 28, 2022
@github-actions
Copy link

github-actions bot commented Oct 28, 2022

Size Change: +15.6 kB (+1%)

Total Size: 1.31 MB

Filename Size Change
build/block-directory/style-rtl.css 1.02 kB +26 B (+3%)
build/block-directory/style.css 1.02 kB +26 B (+3%)
build/block-editor/default-editor-styles-rtl.css 401 B +23 B (+6%) 🔍
build/block-editor/default-editor-styles.css 401 B +23 B (+6%) 🔍
build/block-editor/index.min.js 177 kB +2.69 kB (+2%)
build/block-editor/style-rtl.css 16.2 kB +348 B (+2%)
build/block-editor/style.css 16.2 kB +340 B (+2%)
build/block-library/blocks/archives/editor-rtl.css 107 B +46 B (+75%) 🆘
build/block-library/blocks/archives/editor.css 106 B +46 B (+77%) 🆘
build/block-library/blocks/archives/style-rtl.css 129 B +39 B (+43%) 🚨
build/block-library/blocks/archives/style.css 129 B +39 B (+43%) 🚨
build/block-library/blocks/audio/editor-rtl.css 185 B +35 B (+23%) 🚨
build/block-library/blocks/audio/editor.css 185 B +35 B (+23%) 🚨
build/block-library/blocks/audio/style-rtl.css 158 B +36 B (+30%) 🚨
build/block-library/blocks/audio/style.css 158 B +36 B (+30%) 🚨
build/block-library/blocks/audio/theme-rtl.css 160 B +34 B (+27%) 🚨
build/block-library/blocks/audio/theme.css 160 B +34 B (+27%) 🚨
build/block-library/blocks/avatar/editor-rtl.css 154 B +38 B (+33%) 🚨
build/block-library/blocks/avatar/editor.css 154 B +38 B (+33%) 🚨
build/block-library/blocks/avatar/style-rtl.css 126 B +42 B (+50%) 🆘
build/block-library/blocks/avatar/style.css 126 B +42 B (+50%) 🆘
build/block-library/blocks/block/editor-rtl.css 338 B +177 B (+110%) 🆘
build/block-library/blocks/block/editor.css 338 B +177 B (+110%) 🆘
build/block-library/blocks/button/editor-rtl.css 514 B +32 B (+7%) 🔍
build/block-library/blocks/button/editor.css 514 B +32 B (+7%) 🔍
build/block-library/blocks/button/style-rtl.css 564 B +32 B (+6%) 🔍
build/block-library/blocks/button/style.css 564 B +32 B (+6%) 🔍
build/block-library/blocks/buttons/editor-rtl.css 373 B +36 B (+11%) ⚠️
build/block-library/blocks/buttons/editor.css 373 B +36 B (+11%) ⚠️
build/block-library/blocks/buttons/style-rtl.css 368 B +36 B (+11%) ⚠️
build/block-library/blocks/buttons/style.css 368 B +36 B (+11%) ⚠️
build/block-library/blocks/calendar/style-rtl.css 270 B +31 B (+13%) ⚠️
build/block-library/blocks/calendar/style.css 270 B +31 B (+13%) ⚠️
build/block-library/blocks/categories/editor-rtl.css 125 B +41 B (+49%) 🚨
build/block-library/blocks/categories/editor.css 124 B +41 B (+49%) 🚨
build/block-library/blocks/categories/style-rtl.css 138 B +38 B (+38%) 🚨
build/block-library/blocks/categories/style.css 138 B +38 B (+38%) 🚨
build/block-library/blocks/code/editor-rtl.css 102 B +49 B (+92%) 🆘
build/block-library/blocks/code/editor.css 102 B +49 B (+92%) 🆘
build/block-library/blocks/code/style-rtl.css 159 B +38 B (+31%) 🚨
build/block-library/blocks/code/style.css 159 B +38 B (+31%) 🚨
build/block-library/blocks/code/theme-rtl.css 160 B +36 B (+29%) 🚨
build/block-library/blocks/code/theme.css 160 B +36 B (+29%) 🚨
build/block-library/blocks/columns/editor-rtl.css 147 B +39 B (+36%) 🚨
build/block-library/blocks/columns/editor.css 147 B +39 B (+36%) 🚨
build/block-library/blocks/columns/style-rtl.css 442 B +36 B (+9%) 🔍
build/block-library/blocks/columns/style.css 442 B +36 B (+9%) 🔍
build/block-library/blocks/comment-author-avatar/editor-rtl.css 163 B +38 B (+30%) 🚨
build/block-library/blocks/comment-author-avatar/editor.css 163 B +38 B (+30%) 🚨
build/block-library/blocks/comment-content/style-rtl.css 134 B +42 B (+46%) 🚨
build/block-library/blocks/comment-content/style.css 134 B +42 B (+46%) 🚨
build/block-library/blocks/comment-template/style-rtl.css 237 B +38 B (+19%) ⚠️
build/block-library/blocks/comment-template/style.css 236 B +38 B (+19%) ⚠️
build/block-library/blocks/comments-pagination-numbers/editor-rtl.css 159 B +36 B (+29%) 🚨
build/block-library/blocks/comments-pagination-numbers/editor.css 157 B +36 B (+30%) 🚨
build/block-library/blocks/comments-pagination/editor-rtl.css 258 B +36 B (+16%) ⚠️
build/block-library/blocks/comments-pagination/editor.css 249 B +40 B (+19%) ⚠️
build/block-library/blocks/comments-pagination/style-rtl.css 272 B +37 B (+16%) ⚠️
build/block-library/blocks/comments-pagination/style.css 268 B +37 B (+16%) ⚠️
build/block-library/blocks/comments-title/editor-rtl.css 118 B +43 B (+57%) 🆘
build/block-library/blocks/comments-title/editor.css 118 B +43 B (+57%) 🆘
build/block-library/blocks/comments/editor-rtl.css 875 B +35 B (+4%)
build/block-library/blocks/comments/editor.css 874 B +35 B (+4%)
build/block-library/blocks/comments/style-rtl.css 672 B +35 B (+5%) 🔍
build/block-library/blocks/comments/style.css 671 B +35 B (+6%) 🔍
build/block-library/blocks/cover/editor-rtl.css 646 B +34 B (+6%) 🔍
build/block-library/blocks/cover/editor.css 647 B +34 B (+6%) 🔍
build/block-library/blocks/cover/style-rtl.css 1.6 kB +36 B (+2%)
build/block-library/blocks/cover/style.css 1.59 kB +37 B (+2%)
build/block-library/blocks/embed/editor-rtl.css 327 B +34 B (+12%) ⚠️
build/block-library/blocks/embed/editor.css 327 B +34 B (+12%) ⚠️
build/block-library/blocks/embed/style-rtl.css 446 B +36 B (+9%) 🔍
build/block-library/blocks/embed/style.css 446 B +36 B (+9%) 🔍
build/block-library/blocks/embed/theme-rtl.css 160 B +34 B (+27%) 🚨
build/block-library/blocks/embed/theme.css 160 B +34 B (+27%) 🚨
build/block-library/blocks/file/editor-rtl.css 335 B +35 B (+12%) ⚠️
build/block-library/blocks/file/editor.css 335 B +35 B (+12%) ⚠️
build/block-library/blocks/file/style-rtl.css 288 B +35 B (+14%) ⚠️
build/block-library/blocks/file/style.css 288 B +34 B (+13%) ⚠️
build/block-library/blocks/freeform/editor-rtl.css 2.47 kB +32 B (+1%)
build/block-library/blocks/freeform/editor.css 2.47 kB +30 B (+1%)
build/block-library/blocks/gallery/editor-rtl.css 978 B +30 B (+3%)
build/block-library/blocks/gallery/editor.css 981 B +31 B (+3%)
build/block-library/blocks/gallery/style-rtl.css 1.56 kB +33 B (+2%)
build/block-library/blocks/gallery/style.css 1.56 kB +33 B (+2%)
build/block-library/blocks/gallery/theme-rtl.css 144 B +36 B (+33%) 🚨
build/block-library/blocks/gallery/theme.css 144 B +36 B (+33%) 🚨
build/block-library/blocks/group/editor-rtl.css 687 B +33 B (+5%) 🔍
build/block-library/blocks/group/editor.css 687 B +33 B (+5%) 🔍
build/block-library/blocks/group/style-rtl.css 105 B +48 B (+84%) 🆘
build/block-library/blocks/group/style.css 105 B +48 B (+84%) 🆘
build/block-library/blocks/group/theme-rtl.css 125 B +47 B (+60%) 🆘
build/block-library/blocks/group/theme.css 125 B +47 B (+60%) 🆘
build/block-library/blocks/heading/style-rtl.css 128 B +52 B (+68%) 🆘
build/block-library/blocks/heading/style.css 128 B +52 B (+68%) 🆘
build/block-library/blocks/html/editor-rtl.css 360 B +33 B (+10%) ⚠️
build/block-library/blocks/html/editor.css 362 B +33 B (+10%) ⚠️
build/block-library/blocks/image/editor-rtl.css 912 B +32 B (+4%)
build/block-library/blocks/image/editor.css 912 B +32 B (+4%)
build/block-library/blocks/image/style-rtl.css 662 B +35 B (+6%) 🔍
build/block-library/blocks/image/style.css 666 B +36 B (+6%) 🔍
build/block-library/blocks/image/theme-rtl.css 159 B +33 B (+26%) 🚨
build/block-library/blocks/image/theme.css 159 B +33 B (+26%) 🚨
build/block-library/blocks/latest-comments/style-rtl.css 333 B +35 B (+12%) ⚠️
build/block-library/blocks/latest-comments/style.css 333 B +35 B (+12%) ⚠️
build/block-library/blocks/latest-posts/editor-rtl.css 250 B +37 B (+17%) ⚠️
build/block-library/blocks/latest-posts/editor.css 249 B +37 B (+17%) ⚠️
build/block-library/blocks/latest-posts/style-rtl.css 514 B +36 B (+8%) 🔍
build/block-library/blocks/latest-posts/style.css 514 B +36 B (+8%) 🔍
build/block-library/blocks/list/style-rtl.css 135 B +47 B (+53%) 🆘
build/block-library/blocks/list/style.css 135 B +47 B (+53%) 🆘
build/block-library/blocks/media-text/editor-rtl.css 300 B +34 B (+13%) ⚠️
build/block-library/blocks/media-text/editor.css 298 B +35 B (+13%) ⚠️
build/block-library/blocks/media-text/style-rtl.css 540 B +33 B (+7%) 🔍
build/block-library/blocks/media-text/style.css 539 B +34 B (+7%) 🔍
build/block-library/blocks/more/editor-rtl.css 465 B +34 B (+8%) 🔍
build/block-library/blocks/more/editor.css 465 B +34 B (+8%) 🔍
build/block-library/blocks/navigation-link/editor-rtl.css 742 B +30 B (+4%)
build/block-library/blocks/navigation-link/editor.css 741 B +30 B (+4%)
build/block-library/blocks/navigation-link/style-rtl.css 153 B +38 B (+33%) 🚨
build/block-library/blocks/navigation-link/style.css 153 B +38 B (+33%) 🚨
build/block-library/blocks/navigation-submenu/editor-rtl.css 329 B +33 B (+11%) ⚠️
build/block-library/blocks/navigation-submenu/editor.css 329 B +34 B (+12%) ⚠️
build/block-library/blocks/navigation/editor-rtl.css 2.18 kB +33 B (+2%)
build/block-library/blocks/navigation/editor.css 2.19 kB +33 B (+2%)
build/block-library/blocks/navigation/style-rtl.css 2.25 kB +39 B (+2%)
build/block-library/blocks/navigation/style.css 2.24 kB +35 B (+2%)
build/block-library/blocks/navigation/view-modal.min.js 2.81 kB +27 B (+1%)
build/block-library/blocks/nextpage/editor-rtl.css 428 B +33 B (+8%) 🔍
build/block-library/blocks/nextpage/editor.css 428 B +33 B (+8%) 🔍
build/block-library/blocks/page-list/editor-rtl.css 397 B +34 B (+9%) 🔍
build/block-library/blocks/page-list/editor.css 398 B +35 B (+10%) ⚠️
build/block-library/blocks/page-list/style-rtl.css 212 B +37 B (+21%) 🚨
build/block-library/blocks/page-list/style.css 212 B +37 B (+21%) 🚨
build/block-library/blocks/paragraph/editor-rtl.css 214 B +40 B (+23%) 🚨
build/block-library/blocks/paragraph/editor.css 214 B +40 B (+23%) 🚨
build/block-library/blocks/paragraph/style-rtl.css 321 B +42 B (+15%) ⚠️
build/block-library/blocks/paragraph/style.css 321 B +40 B (+14%) ⚠️
build/block-library/blocks/post-author/style-rtl.css 212 B +37 B (+21%) 🚨
build/block-library/blocks/post-author/style.css 212 B +36 B (+20%) 🚨
build/block-library/blocks/post-comments-form/editor-rtl.css 137 B +41 B (+43%) 🚨
build/block-library/blocks/post-comments-form/editor.css 137 B +41 B (+43%) 🚨
build/block-library/blocks/post-comments-form/style-rtl.css 536 B +35 B (+7%) 🔍
build/block-library/blocks/post-comments-form/style.css 537 B +36 B (+7%) 🔍
build/block-library/blocks/post-date/style-rtl.css 107 B +46 B (+75%) 🆘
build/block-library/blocks/post-date/style.css 107 B +46 B (+75%) 🆘
build/block-library/blocks/post-excerpt/editor-rtl.css 119 B +46 B (+63%) 🆘
build/block-library/blocks/post-excerpt/editor.css 119 B +46 B (+63%) 🆘
build/block-library/blocks/post-excerpt/style-rtl.css 116 B +47 B (+68%) 🆘
build/block-library/blocks/post-excerpt/style.css 116 B +47 B (+68%) 🆘
build/block-library/blocks/post-featured-image/editor-rtl.css 620 B +34 B (+6%) 🔍
build/block-library/blocks/post-featured-image/editor.css 618 B +34 B (+6%) 🔍
build/block-library/blocks/post-featured-image/style-rtl.css 346 B +31 B (+10%) ⚠️
build/block-library/blocks/post-featured-image/style.css 346 B +31 B (+10%) ⚠️
build/block-library/blocks/post-navigation-link/style-rtl.css 190 B +37 B (+24%) 🚨
build/block-library/blocks/post-navigation-link/style.css 189 B +36 B (+24%) 🚨
build/block-library/blocks/post-template/editor-rtl.css 140 B +41 B (+41%) 🚨
build/block-library/blocks/post-template/editor.css 139 B +41 B (+42%) 🚨
build/block-library/blocks/post-template/style-rtl.css 317 B +35 B (+12%) ⚠️
build/block-library/blocks/post-template/style.css 317 B +35 B (+12%) ⚠️
build/block-library/blocks/post-terms/style-rtl.css 136 B +40 B (+42%) 🚨
build/block-library/blocks/post-terms/style.css 136 B +40 B (+42%) 🚨
build/block-library/blocks/post-title/style-rtl.css 138 B +38 B (+38%) 🚨
build/block-library/blocks/post-title/style.css 138 B +38 B (+38%) 🚨
build/block-library/blocks/preformatted/style-rtl.css 139 B +36 B (+35%) 🚨
build/block-library/blocks/preformatted/style.css 139 B +36 B (+35%) 🚨
build/block-library/blocks/pullquote/editor-rtl.css 170 B +35 B (+26%) 🚨
build/block-library/blocks/pullquote/editor.css 170 B +35 B (+26%) 🚨
build/block-library/blocks/pullquote/style-rtl.css 357 B +31 B (+10%) ⚠️
build/block-library/blocks/pullquote/style.css 357 B +32 B (+10%) ⚠️
build/block-library/blocks/pullquote/theme-rtl.css 201 B +34 B (+20%) 🚨
build/block-library/blocks/pullquote/theme.css 201 B +34 B (+20%) 🚨
build/block-library/blocks/query-pagination-numbers/editor-rtl.css 158 B +36 B (+30%) 🚨
build/block-library/blocks/query-pagination-numbers/editor.css 156 B +35 B (+29%) 🚨
build/block-library/blocks/query-pagination/editor-rtl.css 258 B +37 B (+17%) ⚠️
build/block-library/blocks/query-pagination/editor.css 247 B +36 B (+17%) ⚠️
build/block-library/blocks/query-pagination/style-rtl.css 326 B +38 B (+13%) ⚠️
build/block-library/blocks/query-pagination/style.css 322 B +38 B (+13%) ⚠️
build/block-library/blocks/query-title/style-rtl.css 108 B +45 B (+71%) 🆘
build/block-library/blocks/query-title/style.css 108 B +45 B (+71%) 🆘
build/block-library/blocks/query/editor-rtl.css 475 B +35 B (+8%) 🔍
build/block-library/blocks/query/editor.css 477 B +37 B (+8%) 🔍
build/block-library/blocks/quote/style-rtl.css 253 B +40 B (+19%) ⚠️
build/block-library/blocks/quote/style.css 253 B +40 B (+19%) ⚠️
build/block-library/blocks/quote/theme-rtl.css 255 B +32 B (+14%) ⚠️
build/block-library/blocks/quote/theme.css 259 B +33 B (+15%) ⚠️
build/block-library/blocks/read-more/style-rtl.css 168 B +36 B (+27%) 🚨
build/block-library/blocks/read-more/style.css 168 B +36 B (+27%) 🚨
build/block-library/blocks/rss/editor-rtl.css 239 B +37 B (+18%) ⚠️
build/block-library/blocks/rss/editor.css 240 B +36 B (+18%) ⚠️
build/block-library/blocks/rss/style-rtl.css 323 B +34 B (+12%) ⚠️
build/block-library/blocks/rss/style.css 323 B +35 B (+12%) ⚠️
build/block-library/blocks/search/editor-rtl.css 205 B +40 B (+24%) 🚨
build/block-library/blocks/search/editor.css 205 B +40 B (+24%) 🚨
build/block-library/blocks/search/style-rtl.css 441 B +32 B (+8%) 🔍
build/block-library/blocks/search/style.css 439 B +33 B (+8%) 🔍
build/block-library/blocks/search/theme-rtl.css 149 B +35 B (+31%) 🚨
build/block-library/blocks/search/theme.css 149 B +35 B (+31%) 🚨
build/block-library/blocks/separator/editor-rtl.css 184 B +38 B (+26%) 🚨
build/block-library/blocks/separator/editor.css 184 B +38 B (+26%) 🚨
build/block-library/blocks/separator/style-rtl.css 269 B +35 B (+15%) ⚠️
build/block-library/blocks/separator/style.css 269 B +35 B (+15%) ⚠️
build/block-library/blocks/separator/theme-rtl.css 229 B +35 B (+18%) ⚠️
build/block-library/blocks/separator/theme.css 229 B +35 B (+18%) ⚠️
build/block-library/blocks/shortcode/editor-rtl.css 498 B +34 B (+7%) 🔍
build/block-library/blocks/shortcode/editor.css 498 B +34 B (+7%) 🔍
build/block-library/blocks/site-logo/editor-rtl.css 522 B +32 B (+7%) 🔍
build/block-library/blocks/site-logo/editor.css 522 B +32 B (+7%) 🔍
build/block-library/blocks/site-logo/style-rtl.css 238 B +35 B (+17%) ⚠️
build/block-library/blocks/site-logo/style.css 238 B +35 B (+17%) ⚠️
build/block-library/blocks/site-tagline/editor-rtl.css 129 B +43 B (+50%) 🆘
build/block-library/blocks/site-tagline/editor.css 129 B +43 B (+50%) 🆘
build/block-library/blocks/site-title/editor-rtl.css 155 B +39 B (+34%) 🚨
build/block-library/blocks/site-title/editor.css 155 B +39 B (+34%) 🚨
build/block-library/blocks/site-title/style-rtl.css 101 B +44 B (+77%) 🆘
build/block-library/blocks/site-title/style.css 101 B +44 B (+77%) 🆘
build/block-library/blocks/social-link/editor-rtl.css 219 B +35 B (+19%) ⚠️
build/block-library/blocks/social-link/editor.css 219 B +35 B (+19%) ⚠️
build/block-library/blocks/social-links/editor-rtl.css 709 B +35 B (+5%) 🔍
build/block-library/blocks/social-links/editor.css 708 B +35 B (+5%) 🔍
build/block-library/blocks/social-links/style-rtl.css 1.43 kB +36 B (+3%)
build/block-library/blocks/social-links/style.css 1.43 kB +36 B (+3%)
build/block-library/blocks/spacer/editor-rtl.css 360 B +38 B (+12%) ⚠️
build/block-library/blocks/spacer/editor.css 360 B +38 B (+12%) ⚠️
build/block-library/blocks/spacer/style-rtl.css 96 B +48 B (+100%) 🆘
build/block-library/blocks/spacer/style.css 96 B +48 B (+100%) 🆘
build/block-library/blocks/table/editor-rtl.css 537 B +32 B (+6%) 🔍
build/block-library/blocks/table/editor.css 537 B +32 B (+6%) 🔍
build/block-library/blocks/table/style-rtl.css 664 B +33 B (+5%) 🔍
build/block-library/blocks/table/style.css 663 B +32 B (+5%) 🔍
build/block-library/blocks/table/theme-rtl.css 207 B +35 B (+20%) 🚨
build/block-library/blocks/table/theme.css 207 B +35 B (+20%) 🚨
build/block-library/blocks/tag-cloud/style-rtl.css 287 B +36 B (+14%) ⚠️
build/block-library/blocks/tag-cloud/style.css 288 B +35 B (+14%) ⚠️
build/block-library/blocks/template-part/editor-rtl.css 436 B +201 B (+86%) 🆘
build/block-library/blocks/template-part/editor.css 436 B +201 B (+86%) 🆘
build/block-library/blocks/template-part/theme-rtl.css 139 B +38 B (+38%) 🚨
build/block-library/blocks/template-part/theme.css 139 B +38 B (+38%) 🚨
build/block-library/blocks/text-columns/editor-rtl.css 135 B +40 B (+42%) 🚨
build/block-library/blocks/text-columns/editor.css 135 B +40 B (+42%) 🚨
build/block-library/blocks/text-columns/style-rtl.css 198 B +32 B (+19%) ⚠️
build/block-library/blocks/text-columns/style.css 198 B +32 B (+19%) ⚠️
build/block-library/blocks/verse/style-rtl.css 130 B +43 B (+49%) 🚨
build/block-library/blocks/verse/style.css 130 B +43 B (+49%) 🚨
build/block-library/blocks/video/editor-rtl.css 720 B +29 B (+4%)
build/block-library/blocks/video/editor.css 723 B +29 B (+4%)
build/block-library/blocks/video/style-rtl.css 212 B +38 B (+22%) 🚨
build/block-library/blocks/video/style.css 212 B +38 B (+22%) 🚨
build/block-library/blocks/video/theme-rtl.css 160 B +34 B (+27%) 🚨
build/block-library/blocks/video/theme.css 160 B +34 B (+27%) 🚨
build/block-library/classic-rtl.css 193 B +31 B (+19%) ⚠️
build/block-library/classic.css 193 B +31 B (+19%) ⚠️
build/block-library/common-rtl.css 1.05 kB +27 B (+3%)
build/block-library/common.css 1.04 kB +26 B (+3%)
build/block-library/editor-elements-rtl.css 126 B +51 B (+68%) 🆘
build/block-library/editor-elements.css 126 B +51 B (+68%) 🆘
build/block-library/editor-rtl.css 11.7 kB +258 B (+2%)
build/block-library/editor.css 11.7 kB +259 B (+2%)
build/block-library/elements-rtl.css 105 B +51 B (+94%) 🆘
build/block-library/elements.css 105 B +51 B (+94%) 🆘
build/block-library/index.min.js 194 kB +707 B (0%)
build/block-library/reset-rtl.css 514 B +36 B (+8%) 🔍
build/block-library/reset.css 514 B +36 B (+8%) 🔍
build/block-library/style-rtl.css 12.4 kB +36 B (0%)
build/block-library/style.css 12.4 kB +36 B (0%)
build/block-library/theme-rtl.css 735 B +31 B (+4%)
build/block-library/theme.css 740 B +32 B (+5%) 🔍
build/blocks/index.min.js 49.9 kB -3 B (0%)
build/components/index.min.js 203 kB +181 B (0%)
build/components/style-rtl.css 11.5 kB +28 B (0%)
build/components/style.css 11.6 kB +28 B (0%)
build/compose/index.min.js 12.2 kB +1 B (0%)
build/customize-widgets/style-rtl.css 1.41 kB +26 B (+2%)
build/customize-widgets/style.css 1.41 kB +27 B (+2%)
build/edit-navigation/index.min.js 16.2 kB -15 B (0%)
build/edit-navigation/style-rtl.css 4.08 kB +31 B (+1%)
build/edit-navigation/style.css 4.09 kB +30 B (+1%)
build/edit-post/classic-rtl.css 569 B +23 B (+4%)
build/edit-post/classic.css 570 B +23 B (+4%)
build/edit-post/index.min.js 34.4 kB -138 B (0%)
build/edit-post/style-rtl.css 7.42 kB +33 B (0%)
build/edit-post/style.css 7.41 kB +33 B (0%)
build/edit-site/index.min.js 61 kB -95 B (0%)
build/edit-site/style-rtl.css 8.48 kB +96 B (+1%)
build/edit-site/style.css 8.46 kB +105 B (+1%)
build/edit-widgets/index.min.js 16.7 kB -16 B (0%)
build/edit-widgets/style-rtl.css 4.44 kB +36 B (+1%)
build/edit-widgets/style.css 4.44 kB +34 B (+1%)
build/editor/index.min.js 43.7 kB +17 B (0%)
build/editor/style-rtl.css 3.63 kB +28 B (+1%)
build/editor/style.css 3.62 kB +28 B (+1%)
build/format-library/style-rtl.css 596 B +25 B (+4%)
build/format-library/style.css 596 B +25 B (+4%)
build/list-reusable-blocks/style-rtl.css 858 B +23 B (+3%)
build/list-reusable-blocks/style.css 857 B +22 B (+3%)
build/nux/style-rtl.css 759 B +27 B (+4%)
build/nux/style.css 755 B +27 B (+4%)
build/reusable-blocks/style-rtl.css 281 B +25 B (+10%) ⚠️
build/reusable-blocks/style.css 281 B +25 B (+10%) ⚠️
build/widgets/style-rtl.css 1.21 kB +25 B (+2%)
build/widgets/style.css 1.21 kB +24 B (+2%)
ℹ️ View Unchanged
Filename Size
build/a11y/index.min.js 982 B
build/annotations/index.min.js 2.76 kB
build/api-fetch/index.min.js 2.26 kB
build/autop/index.min.js 2.14 kB
build/blob/index.min.js 475 B
build/block-directory/index.min.js 7.09 kB
build/block-library/blocks/file/view.min.js 346 B
build/block-library/blocks/navigation/view.min.js 443 B
build/block-serialization-default-parser/index.min.js 1.12 kB
build/block-serialization-spec-parser/index.min.js 2.83 kB
build/core-data/index.min.js 15.5 kB
build/customize-widgets/index.min.js 11.3 kB
build/data-controls/index.min.js 653 B
build/data/index.min.js 8.08 kB
build/date/index.min.js 32.1 kB
build/deprecated/index.min.js 507 B
build/dom-ready/index.min.js 324 B
build/dom/index.min.js 4.7 kB
build/element/index.min.js 4.68 kB
build/escape-html/index.min.js 537 B
build/experiments/index.min.js 868 B
build/format-library/index.min.js 6.95 kB
build/hooks/index.min.js 1.64 kB
build/html-entities/index.min.js 448 B
build/i18n/index.min.js 3.77 kB
build/is-shallow-equal/index.min.js 527 B
build/keyboard-shortcuts/index.min.js 1.78 kB
build/keycodes/index.min.js 1.83 kB
build/list-reusable-blocks/index.min.js 2.13 kB
build/media-utils/index.min.js 2.93 kB
build/notices/index.min.js 963 B
build/nux/index.min.js 2.06 kB
build/plugins/index.min.js 1.94 kB
build/preferences-persistence/index.min.js 2.22 kB
build/preferences/index.min.js 1.33 kB
build/primitives/index.min.js 944 B
build/priority-queue/index.min.js 1.58 kB
build/react-i18n/index.min.js 696 B
build/react-refresh-entry/index.min.js 8.44 kB
build/react-refresh-runtime/index.min.js 7.31 kB
build/redux-routine/index.min.js 2.74 kB
build/reusable-blocks/index.min.js 2.21 kB
build/rich-text/index.min.js 10.7 kB
build/server-side-render/index.min.js 1.77 kB
build/shortcode/index.min.js 1.53 kB
build/style-engine/index.min.js 1.48 kB
build/token-list/index.min.js 644 B
build/url/index.min.js 3.61 kB
build/vendors/inert-polyfill.min.js 2.48 kB
build/vendors/react-dom.min.js 38.5 kB
build/vendors/react.min.js 4.34 kB
build/viewport/index.min.js 1.08 kB
build/warning/index.min.js 268 B
build/widgets/index.min.js 7.21 kB
build/wordcount/index.min.js 1.06 kB

compressed-size-action

@andrewserong
Copy link
Contributor

andrewserong commented Oct 30, 2022

This is a very initial stages WIP

In case it helps for looking into width controls: there was an earlier working exploration into adding a width support back in #32502 from @aaronrobertshaw, and I've got a current PR that's looking into adding minHeight support over in #45300. These are slightly different use cases (adding general dimensions block supports to blocks, rather than focusing on exposing controls of the child of a particular type of Layout block), but just thought I'd share them in case it helps with the exploration here at all 🙂

Copy link
Contributor

@andrewserong andrewserong left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Great work so far @tellthemachines, this is testing pretty well! Added a few questions and thoughts.

We probably don't want "Child layout" to be the name of this section; I called it that for now to tell it apart from the "Layout" section in blocks that have both:

This might require some refactoring (which we probably already need to do as part of #44560), but I was wondering if we can include these controls under the existing Layout panel? Because these controls only apply to children of a layout, I imagine we won't run into any collisions, so that a child of a layout can have these controls and their own layout controls in the same panel, which might be easier for a user to interact with. From the user's perspective (hopefully!) each of the controls there are things that affect the layout of that selected block, whether that's because of inherited / parent values or not?

Also, I like the choice to refer to this control as size, as opposed to Width, since the behaviour using flex-basis is quite different to the width CSS property. And separately to this PR there could still be good value in exploring a dedicated Width block support. This is likely a question for designers, but I wonder how this new control in layout would work alongside width controls (e.g. those currently in Button, Search, or Image blocks) 🤔.

A couple of other first impressions:

  • Should this be an explicit opt-in / setting for layout? It's nice having this available for children of the Row block, but it seemed a bit unexpected for social icons to me.
  • When setting a fixed size (e.g. 50%) the flex-basis value does not include a calculation using the current block spacing, so if I set 50% width on two children of the Row block, then the overall area will overflow:

image

Is it worth exploring adding in a calculation in the style output similar to how the width styling works on individual button blocks? The Button block's width control currently attempts to use the --wp--style--block-gap CSS variable, so falls apart if the parent Buttons block sets its own blockGap value — however, since this PR adds behaviour to the layout support, we should hopefully be able to grab the real value we want to use, if we incorporate similar logic here. Here's the Button block's rule:

image

Related to the issue of calculating width, when a fixed value is in use, should we also output a box-sizing: border-box rule in addition to flex-basis? Without it, if a Paragraph block has padding, then we also have the issue of the block overflowing unexpectedly:

image

Other than dealing with those finicky details, I think this is going to be such a useful feature, particularly being able to choose between Hug and Fill quickly without having to think about custom / specific CSS values.

...style,
layout: {
...layout,
flexSize: value,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is flexSize always going to be output as flex-basis? If so, I was wondering if we can use the latter, since the style object tries to stick closer to CSS properties where possible (where the root layout object appears to currently be a bit more abstract).

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I was trying to avoid giving it the property name in favour of a name that's clearer as to what it does, mainly because flexSize translates into more than one property (right now it's flex-shrink and flex-basis, but we might add border-box as per your suggestion, things might change etc.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I was trying to avoid giving it the property name in favour of a name that's clearer as to what it does, mainly because flexSize translates into more than one property

Good point! Yes, for these ones that result in multiple / combined rules being output (or additional logic) that makes good sense to me, a bit like how blockGap doesn't directly correspond to gap 👍

I've also been wondering when it makes most sense to store things in the layout object directly or when to store them in style.layout. I quite like the decision to use style.layout here, personally, but I wondered if you had an idea in mind of when we make the call between the two? One possibility is when we aren't selecting from a controlled list of options (so things that aren't alignment based like content justification), style.layout might be the better fit?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

My idea here was to keep the layout attribute exclusively for blocks that have layout themselves, and use style.layout for styles that are related to a parent's layout.

/>
<ToggleGroupControlOption
key={ 'fixed' }
value={ 'fixed' }
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could "fixed" cause confusion with the fixed/sticky position support once we have both of these features in? I wonder if there's another name we can use for entering a custom value 🤔

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's a good question! I'd defer to design on that one 😅

$child_layout_styles[] = array(
'selector' => ".$container_content_class",
'declarations' => array(
'flex-shrink' => '0',
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh, this is an interesting one. I assume this is to attempt to preserve what a user has chosen?

Will we always want to prevent the element from shrinking? That is, if someone sets a large value for flex-basis (e.g. 900px) I was wondering if we'll want to preserve that in smaller viewports where it'll cause an overflow, or in desktop viewports where it'll also overflow contentSize?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, if we set a fixed size we do want to prevent it from shrinking. That's touched upon in this comment, but also if we don't set flex-shrink there's no way to make sure the block actually sticks to the defined size 😅
As users are deliberately setting values, I think it's fine for them to overflow their containers where the values are too large.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As users are deliberately setting values, I think it's fine for them to overflow their containers where the values are too large.

Ah, I see your point! It's a tricky one to work out the desired behaviour here (whether to honour what the user is attempting to do, or try to make sure they don't break the layout). I think I probably lean more toward preventing them from overflowing the container, because otherwise it breaks outside of the content size / wide size logic, which could be unexpected, and any width that's set greater than 400px would overflow most phone's viewports in a vertical orientation. Here's a paragraph set to 500px on desktop and mobile:

Desktop Mobile
image image

From a quick look at the Column block's ad hoc width control, it appears that it currently doesn't include a flex-shrink: 0 rule, so it currently ensures that Columns blocks don't break out.

Either way, though, since these CSS rules aren't baked into post content, it looks like it'll be a simple rule to change if we want to 🙂

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Interesting balance to strike on this one. In general, it seems like we try to start from a position of encouraging good design choices by default, then move towards honouring user choices. Following that, I'd lean a little more toward not allowing the broken layout first, then honouring explicit choices second.

That's only my naive two cents though, so take it with a grain of salt 🤷‍♂️

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure it's helpful to think of this situation as a "broken layout", because people might want to create a horizontally scrolling page, and currently there's no way to do so in the site editor. It's easy enough to undo a change, and obvious enough that a horizontal scroll is happening if the user does add a bunch of fixed widths by accident, that we should let it happen.

Also, as I said before, there's no way of making this feature work properly without the flex-shrink in place. If we show a control to fix the width of a block, and that control doesn't actually fix it, that's a much more broken experience than allowing users the possibility of making their page scroll horizontally.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it's a really interesting argument in both directions here (whether to honour the user's explicit choice, or attempt to do a fuzzy approximation). With other width controls (e.g. Columns or Search block), it looks like we currently don't allow overflowing the container? The search block sets the width value explicitly, but also has max-width: 100% so it doesn't overflow.

In terms of which user intent to prioritise, I'd be curious to hear thoughts from @jasmussen on this one — for a bit of history, there's been prior attempts to land a width block support, and the responsive behaviour was flagged on an earlier attempt here: #32502 (comment), and there's a subsequent open issue for responsive / intrinsic web design and how it relates to block controls in: #34641.

Whichever way we prioritise, I think it'd be good to figure out how we can support the one we haven't prioritised. E.g. if we went with the fuzzy approach, how do we then allow folks to intentionally create horizontally scrolling layouts, and alternately, if we honour the explicit pixel width, how do we allow folks to set a larger size that then shrinks in smaller viewports.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It was @jasmussen's recommendation here to let explicit widths break out of their container 😄

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah, good catch, thanks @tellthemachines, I missed that one! That's a more recent comment so more likely captures the current thinking 🙂

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No worries, it's always good to poke at stuff anyway and see how we can improve it!

I think in this case the fuzzy approach would add too much complexity for the value it might bring: removing the flex-shrink would stop the setting from working as expected, so we'd probably have to do some calculation of parent widths or something horrible like that 😬

Also, given we already have Columns with the width constraints, it makes sense to have this behave differently, so folks can use Columns for a content-width-respecting layout and Row for more freestyle options.

I'm actually pretty excited to finally have a way to create fixed width, horizontally scrolling pages tbh 😁

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Great points, and there's nothing stopping us from adding a fluid or fuzzy option as an additional control alongside fixed in a follow-up at some point to handle the case where someone wants to set a target width that gets either shrunk or clampified 👍

@jasmussen
Copy link
Contributor

jasmussen commented Nov 2, 2022

Took it for a spin. Here's the row block before, with no width controls:

row before

Here it is after, with new controls:

row after

First instinct: this is going to afford some excellent new designs and adds incredible power to the flex blocks. Well done — fill, hug, and fixed width controls seem to be working as well as I hoped they would. Nice.

A few thoughts on the UI, though. We should seek to avoid a new panel if at all possible. The designs in #44467 put it inside the Layout panel, which at that point is a toolspanel to allow defaults.

Inner block i2

The tools panel as well as defaults (for example showing some controls by default if a parent, showing others if a child) is understandable to be a challenge, but it still seems best to keep all controls inside the same panel for now. Possible?

Should we add the contextual help text from the mockups?

There should ideally be 8px gap between the segmented control and the "fixed" width input field, a la this grid:

Grid

That may be on the component level, just as the 40px control height is, not sure, just want to make sure it's noted and that this will benefit from any component-wide changes made.

Can we call it "Width" instead of "Relative size"? I can imagine that the size moniker was chosen because the parent can be switched to be a stack instead. But can we change the label to "Height" on the stack instead?

What do you think?

Nice work.

@jameskoster
Copy link
Contributor

+1 to everything Joen said, including "nice work", this is really going to unlock so many ways to express layout.

One thing I noticed: if you create a Row containing two paragraphs, both set to fill, then add another Row inside the original one (also set to fill), then widths aren't calculated correctly. The children should all have equal widths. The paragraphs are equal, but the row is not, as you can see in the video below:

width.mp4

Code example to replicate:

<div class="wp-block-group"><!-- wp:paragraph {"style":{"layout":{"selfStretch":"fill","flexSize":"-23px"}}} -->
<p>Hello</p>
<!-- /wp:paragraph -->

<!-- wp:paragraph {"style":{"layout":{"selfStretch":"fill","flexSize":"-23px"}}} -->
<p>Hello</p>
<!-- /wp:paragraph -->

<!-- wp:group {"style":{"layout":{"selfStretch":"fill"}},"layout":{"type":"flex","flexWrap":"nowrap"}} -->
<div class="wp-block-group"><!-- wp:paragraph {"style":{"layout":{"selfStretch":"hug","flexSize":"-23px"}}} -->
<p>Hi</p>
<!-- /wp:paragraph -->

<!-- wp:paragraph {"style":{"layout":{"selfStretch":"hug","flexSize":"-23px"}}} -->
<p>Hi</p>
<!-- /wp:paragraph --></div>
<!-- /wp:group --></div>
<!-- /wp:group -->```



@tellthemachines
Copy link
Contributor Author

Thanks for the feedback and testing everyone!

We can make these child controls part of the main layout panel, no problem. In case a given block has both parent and child controls, how should we organise them? (I guess once we move to using tools panel, the question will be which should be visible by default?)

Should this be an explicit opt-in / setting for layout? It's nice having this available for children of the Row block, but it seemed a bit unexpected for social icons to me.

Yes, it should be! Funnily enough, I looked at Buttons and Navigation, and not seeing the controls appear, assumed they weren't working for any other blocks (not sure why - I'd expect them to just work wherever we're using flex layout) but forgot to check Social 😅 I do kind of like the aesthetic possibilities:

Screenshot 2022-11-03 at 3 23 59 pm

but notice the values set aren't being saved, so best turn this off for all blocks except Group until we work out what to do.

When setting a fixed size (e.g. 50%) the flex-basis value does not include a calculation using the current block spacing, so if I set 50% width on two children of the Row block, then the overall area will overflow

One thing I noticed: if you create a Row containing two paragraphs, both set to fill, then add another Row inside the original one (also set to fill), then widths aren't calculated correctly. The children should all have equal widths. The paragraphs are equal, but the row is not

So this is where I don't think we'll be able to hack it with just the child controls. I left a note on the issue suggesting we have a parent-level control for fixing all children at the same width. That way we can make it Just Work independently of how many children exist, or are added/removed later.

Related to the issue of calculating width, when a fixed value is in use, should we also output a box-sizing: border-box rule in addition to flex-basis

⭐ excellent idea!

Can we call it "Width" instead of "Relative size"? I can imagine that the size moniker was chosen because the parent can be switched to be a stack instead. But can we change the label to "Height" on the stack instead?

We should be able to do this, I'll look into it!

@andrewserong
Copy link
Contributor

Thanks for the follow-up!

I do kind of like the aesthetic possibilities:

Actually, yeah that example there is super cute. I suspect that once these controls are rolled out more broadly there'll be heaps of opportunities for fun and creative layouts. Very exciting! 😀

@aaronrobertshaw
Copy link
Contributor

I'm a bit late to this party but to play devil's advocate quickly, am I the only one that took a double take at "width" or "size" controls not being under the dimensions panel? I do appreciate their ties to the layout support though.

As a user with no background in CSS, our layouts etc., where would they expect it? This might be more of an issue if those controls aren't displayed by default and therefore hidden within a ToolsPanel ellipsis menu.

@jasmussen
Copy link
Contributor

I'm a bit late to this party but to play devil's advocate quickly, am I the only one that took a double take at "width" or "size" controls not being under the dimensions panel? I do appreciate their ties to the layout support though.

Good take! I have a sense that many of the designs are inspired heavily by Figma where these properties are intrinsically a layout property, defining items and containers lay out their contents. But I could see it live in Dimensions as well. @jameskoster any hot takes?

@jameskoster
Copy link
Contributor

Good catch, the Dimensions panel would be a better fit. Layout is likely best reserved for container blocks – a rule of thumb for me to keep in mind.

So this is where I don't think we'll be able to hack it with just the child controls

It may not be a big deal – my expectations are likely biased based on how Figma behaves :) Looking back at the codepen the behavior is actually working as expected. All that to say: no need to add a parent control as a part of this PR, and may be not at all.

@tellthemachines
Copy link
Contributor Author

As a user with no background in CSS, our layouts etc., where would they expect it? This might be more of an issue if those controls aren't displayed by default and therefore hidden within a ToolsPanel ellipsis menu.

This is an interesting point. My personal take is that it would be better for all the controls currently under Dimensions to be under Layout instead, because the only one we have in there that actually changes dimensions is the recently added Min height 😅

The advantage of having these controls together with the Dimensions ones is that when we display the flex-child width/height control we can easily hide the min-height one, and any potential width control we may yet add, because they'd be redundant.

I guess the disadvantage is that it might be confusing to have width/height appear as options only when the block is within a Row/Stack block, and to have width switch to height if the parent changes from Row to Stack, for instance. Maybe we could mitigate this with some helper text explaining that this control depends on the parent's layout?

@jasmussen
Copy link
Contributor

That surfaces a good point. If the new width control sits in dimensions, it might make more sense for a nested group, which has both child-facing layout properties, and parent-facing width behaviors.

@jameskoster
Copy link
Contributor

Not something to do here but it would be good to explore how we might eliminate the conceptual overlaps that exist between these two panels.

But for now, since everything in the Layout panel currently relates to child blocks within a container, we should probably stick to that heuristic and move these width settings to the Dimensions panel.

@paaljoachim
Copy link
Contributor

paaljoachim commented Nov 8, 2022

Testing
Using the Gutenberg PR build.
WordPress 6.1
Twenty Twenty Three.
Site Editor.

Before:

Screenshot 2022-11-08 at 10 28 29

After:

Screenshot 2022-11-08 at 10 34 47

One of the first things I notice is that the text above the Toggle does not change when going between Hug - Fill - Fixed. I expected this to change.

Dimensions / Layout seems to cross into each others territory. Should these be merged?

@tellthemachines
Copy link
Contributor Author

Dev note (it's a short one so probably should be combined with other relevant layout/design tools) cc @bph @andrewserong

Sizing controls for flex layout children

A new Layout feature was added that allows the children of container blocks with Flex type layout to provide controls to change their relative size within their parent block. This feature can be added to the container block in its __experimentalLayout settings in block.json, like so:

"__experimentalLayout": {
			"allowSizingOnChildren": true,
			"default": {
				"type": "flex"
			}
		}

The controls for the child blocks will then be displayed under the "Dimensions" panel in the block sidebar. If the parent's orientation is horizontal the control will appear as "Width", and if it's vertical it will be "Height".

Three options are available in this control:

  • "Fit" is the default, and means the block will take up only as much space as its intrinsic dimensions;
  • "Fill" makes the block stretch to take up all remaining available space within its parent;
  • "Fixed" allows for setting a fixed width or height (depending on the parent's orientation) in px, %, em, rem, vw or vh units.

Screenshot 2023-02-15 at 10 58 42 am

@skorasaurus
Copy link
Member

Dev note (it's a short one so probably should be combined with other relevant layout/design tools) cc @bph @andrewserong

Sizing controls for flex layout children

A new Layout feature was added that allows the children of container blocks with Flex type layout to provide controls to change their relative size within their parent block. This feature can be added to the container block in its __experimentalLayout settings in block.json, like so:

"__experimentalLayout": {
			"allowSizingOnChildren": true,
			"default": {
				"type": "flex"
			}
		}

Is it intentional that this is missing from the group block ?

@tellthemachines
Copy link
Contributor Author

Is it intentional that this is missing from the group block ?

Absolutely! These controls are specifically for children of flex layouts. Group has a flow/constrained layout.

@bph
Copy link
Contributor

bph commented Feb 28, 2023

I didn't realize before that this is still experimental. __experimentalLayout - should we actually publish about it. I know it will bring a few comments again from core committers. There is the idea that experimental APIs are not documented. This has been a fluid rule, though...
__experimentalLayout - had been around for quite a while now, so it's good practice to document it. I added the Dev note to the Misc Editor Dev note.

dmsnell added a commit that referenced this pull request Aug 30, 2023
…lasses.

In #45364 (WordPress/wordpress-develop#3976) the Block Supports was extended to
add layout class names using the HTML API, new in WordPress 6.2. The initial
patch opened up two opportunities to refine the code, however:

 - There are multiple instances of the `WP_HTML_Tag_Processor` created when a
   single one suffices. (There is an exception in that a second processor is
   necessary in order to find an inner block wrapper).

 - The code relies on the incidental fact that searching by a whitespace-separated
   list of class names works if the class names in the target tag are in the same
   order.

In this patch the use of the HTML API is refactored to address these opportunities
and clean up a few places where there could be stronger consistency with other use
patterns of the HTML API:

 - Multiple instances of the Tag Processor have been combined to remove overhead,
   extra variables, and code confusion. The new flow is more linear throughout the
   function instead of branching.

 - Updated HTML is returned via `get_updated_html()` instead of casting to a string.

 - The matching logic to find the inner block wrapper has been commented and the
   condition uses the null-coalescing operator now that WordPress requires PHP 7.0+.

 - When attempting to find the inner block wrapper at the end, a custom comparison
   is made against the `class` attribute instead of relying on `next_tag()` to find
   a tag with the given set of class names.

The last refactor is important as a preliminary step to WordPress/wordpress-develop#5096
where `has_class()` and `class_list()` methods are being introduced to the Tag Processor.
In that patch the implicit functionality of matching `'class_name' => 'more than one class'`
is removed since that's not a single class name, but many.
dmsnell added a commit that referenced this pull request Sep 1, 2023
…lasses.

In #45364 (WordPress/wordpress-develop#3976) the Block Supports was extended to
add layout class names using the HTML API, new in WordPress 6.2. The initial
patch opened up two opportunities to refine the code, however:

 - There are multiple instances of the `WP_HTML_Tag_Processor` created when a
   single one suffices. (There is an exception in that a second processor is
   necessary in order to find an inner block wrapper).

 - The code relies on the incidental fact that searching by a whitespace-separated
   list of class names works if the class names in the target tag are in the same
   order.

In this patch the use of the HTML API is refactored to address these opportunities
and clean up a few places where there could be stronger consistency with other use
patterns of the HTML API:

 - Multiple instances of the Tag Processor have been combined to remove overhead,
   extra variables, and code confusion. The new flow is more linear throughout the
   function instead of branching.

 - Updated HTML is returned via `get_updated_html()` instead of casting to a string.

 - The matching logic to find the inner block wrapper has been commented and the
   condition uses the null-coalescing operator now that WordPress requires PHP 7.0+.

 - When attempting to find the inner block wrapper at the end, a custom comparison
   is made against the `class` attribute instead of relying on `next_tag()` to find
   a tag with the given set of class names.

The last refactor is important as a preliminary step to WordPress/wordpress-develop#5096
where `has_class()` and `class_list()` methods are being introduced to the Tag Processor.
In that patch the implicit functionality of matching `'class_name' => 'more than one class'`
is removed since that's not a single class name, but many.
dmsnell added a commit that referenced this pull request Sep 4, 2023
…lasses.

In #45364 (WordPress/wordpress-develop#3976) the Block Supports was extended to
add layout class names using the HTML API, new in WordPress 6.2. The initial
patch opened up two opportunities to refine the code, however:

 - There are multiple instances of the `WP_HTML_Tag_Processor` created when a
   single one suffices. (There is an exception in that a second processor is
   necessary in order to find an inner block wrapper).

 - The code relies on the incidental fact that searching by a whitespace-separated
   list of class names works if the class names in the target tag are in the same
   order.

In this patch the use of the HTML API is refactored to address these opportunities
and clean up a few places where there could be stronger consistency with other use
patterns of the HTML API:

 - Multiple instances of the Tag Processor have been combined to remove overhead,
   extra variables, and code confusion. The new flow is more linear throughout the
   function instead of branching.

 - Updated HTML is returned via `get_updated_html()` instead of casting to a string.

 - The matching logic to find the inner block wrapper has been commented and the
   condition uses the null-coalescing operator now that WordPress requires PHP 7.0+.

 - When attempting to find the inner block wrapper at the end, a custom comparison
   is made against the `class` attribute instead of relying on `next_tag()` to find
   a tag with the given set of class names.

The last refactor is important as a preliminary step to WordPress/wordpress-develop#5096
where `has_class()` and `class_list()` methods are being introduced to the Tag Processor.
In that patch the implicit functionality of matching `'class_name' => 'more than one class'`
is removed since that's not a single class name, but many.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
[Feature] Layout Layout block support, its UI controls, and style output. Needs Dev Note Requires a developer note for a major WordPress release cycle Needs User Documentation Needs new user documentation [Type] Enhancement A suggestion for improvement.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Make it possible to set the width of blocks within Row