OpenAI suggested the following labels for this issue:

• [Feature Group] Content Management: The issue pertains to managing the layout of forms, which falls under the broader category of content management features.
• [Feature] Forms Blocks: The issue specifically discusses challenges with form layouts and adding support, making this label relevant.
• [Feature] Custom CSS: The suggestion of adding layout support implies potential customization, which relates to modifying CSS for better styling.

This issue could use some more labels, to help prioritize and categorize our work. Could you please add at least a [Type], a [Feature], and a [Pri] label?

I've started working on a small spike/experiment to see how possible this is.

Adding layout support would solve these issues, but on the flip side potentially add complicated controls, so we need to be careful what exact layout supports we would add.

It looks like the controls can be configured to be hidden. The downside is that while it's pretty customizable, there are some controls like "Allow to wrap to multiple lines" that can't be controlled, and that one in particular doesn't really make sense for forms. The only option is to set allowEditing to false, and that completely hides all layout controls! It's a shame, as it'd be nice to support justification. Still, I think it's not a bad option to hide all layout controls, the block would be able to adopt layout support, but locked down to start with. Perhaps at some point core will support a little more configurability here, and more options can be exposed.

The other thing is that the current layout system for the form block works a little differently to what core expects. It uses what core would consider a 'row' layout, but all the inner blocks are set to 100% width to force them to wrap, unless explicitly specified by the user. I think for Gutenberg's layout system, this would generally be achieved by using a stack, and then any fields that need to be side-by-side would be wrapped in a row within that stack.

The final thing is it's a little challenging to get this working on the frontend, that's what I'm currently solving.

The downside is that while it's pretty customizable, there are some controls like "Allow to wrap to multiple lines" that can't be controlled, and that one in particular doesn't really make sense for forms.

If there isn't a Gutenberg issue yet to make that configurable, it would make sense to document the finding with real use case.

Noting that inline label is a cool feature in core form blocks, but we should be able to achieve the same with layouts support?

Noting that inline label is a cool feature in core form blocks, but we should be able to achieve the same with layouts support?

At the moment I'm only looking at using the layout system for the top-level form block, that way it shouldn't overlap with @aaronrobertshaw's work.

Layouts within fields should hopefully still work (I'll remember to test it).

I'm going to pause my work on this. Here's a write-up of what I've discovered.

TLDR - I don't think this is worth pursuing right now. I think core's layout support needs a few extra enhancements to properly support forms. Grid layout might be an interesting future possibility.

I expect there will also be more opportunities after @aaronrobertshaw's work in #41281, that would unlock what the inline label idea mentioned here by using a row layout in the field block.

Current state

The top-level form block has a flexbox layout with flex-direction: row set.

Most users won't really consider it a horizontal layout, as each field has 100% width by default, so each field takes up the full width and successive fields wrap to the next line. Users can set individual field blocks to different percentage widths to make them appear on the same row:

This side-by-side field layout seems like something the block is optimized for.

Something to note here is that these width percentages automatically take the gap between the blocks into account:

This means the fields always fit nicely into a row:

There are also some responsive styles, on smaller screens the layout reverts to all fields being full-width again.

Porting this to the Block Editor's layout system

One of my hopes had been to switch the form block over to the block editor's layout system to avoid the hard-coded CSS and make it possible for the block to adopt other kinds of layout where it makes sense. Perhaps the default layout could still be fairly simple, but it would still be possible to build something more advanced, especially for style variations and patterns.

Making the block work more idiomatically could also allow a wider variety of child blocks within the form, and they'll just work naturally. An example of how this isn't work so well right now is the way the Button block requires a hard-coded exception to the style rules, and there are a few other examples of this:

Row layout

It's pretty easy to switch to the top-level form block to use a similar flexbox row layout but using the block editor's layout system, just like the Row block. This part works without issue.

The block editor does also offer size controls on the individual fields and it also allows percentage widths:

Unfortunately these widths don't take the block gap into account so the fields won't line up nicely. Here's the same layout as above using the layout system and you can see the fields overflow when set to widths that add up to 100%:

There was some discussion about this in the Gutenberg repo, but I can't see that it has been addressed. The row layout also won't provide the same responsive behavior that the form block currently has without some CSS overrides.

Grid layout

It's possible to achieve a very similar layout using a grid layout in manual mode with 4 columns, and this does solve the problem with block gap:

In a grid, we'd set the column span for each field instead of a width percentage. Unfortunately, there are also no responsive options for this layout.

Still, I think the grid layout might be interesting for forms in the future. There are lots of additional features for grids behind an experiment flag in the Gutenberg plugin that will allow for more responsive behavior with the simpler 'automatic' mode:

It gets pretty close to working how the form block currently does without the need for any special CSS, albeit with a few quirks.

Other layouts

Flow and Constrained layouts are the default layouts in the block editor. 'Constrained' adopts the content width, while 'flow' doesn't restrict the width of blocks. I don't think they'll provide much value for forms, users would have to wrap fields with columns/row/grid to achieve a a layout that has fields side-by-side, which is more complicated than how the block works right now.

I've pushed a draft PR #41665 if you want to try out the layout system on the form block.

I expect there will also be more opportunities after @aaronrobertshaw's work in #41281,

It's worth noting that #41281 isn't intended to land. It was meant as a vehicle for exploring blockers, backward compatibility requirements, necessary compromises, and UX implications of inner blocks on form fields.

My plan is to close that PR today to avoid further expectations that inner blocks for form fields are imminent. If a decision to commit to inner block based form fields is made, a new PR will be created based off the latest on trunk.

Something I forgot to mention in my write-up above, is that users can already add blocks like columns, row, grid and stack inside a form block.

I think this can be a path for users to build different kinds of layouts.

A good outcome of this might be to audit those different layout blocks and make sure field blocks work as expected when used inside them. (there's one issue here already - #41519)

A good outcome of this might be to audit those different layout blocks and make sure field blocks work as expected when used inside them.

This is a good point. We'll need to expand the scope of testing beyond the layout styles too as the current approach to syncing shared styles assumes the fields are immediate children of the parent form block.

I'll create a dedicated issue for this if there isn't already one and work on a fix shortly.

A good outcome of this might be to audit those different layout blocks and make sure field blocks work as expected when used inside them. (there's one issue here already - #41519)

I've done some investigation, and this is also pretty challenging. I'm at a point where the Row, Stack, etc. work ok, but the sizing options on individual form fields within those blocks don't work, which leaves the feature pretty limited. The biggest issue is that form fields renders as shortcodes.

The block editor tries post process the HTML to add generated layout classnames, but it can't process the shortcodes.

In core this is handled by a function wp_render_layout_support_flag. It generates a classname with a unique id:
https://github.com/WordPress/wordpress-develop/blob/ac2eeb9868d995f5632fcfdc40e8b36e22724ba7/src/wp-includes/block-supports/layout.php#L583

Then attaches it to the block's wrapper element:
https://github.com/WordPress/wordpress-develop/blob/ac2eeb9868d995f5632fcfdc40e8b36e22724ba7/src/wp-includes/block-supports/layout.php#L671-L693

It only works with HTML markup, not shortcodes. My current idea is to temporarily render a div wrapper around the shortcode during rendering, which then gets removed before the final output. If that doesn't work, I'm not sure what the other options are (other than changing completely how fields render 😬 ).

My current idea is to temporarily render a div wrapper

Worth a shot 👍

The only other ideas I have would involve upstream changes in core e.g. moving the classname generation to the render_block_data filter and passing it via the $parsed_block for use in the render_block callback. Which would allow the class to be applied to the shortcode and eventually final markup.

A more far-fetched version would be almost duplicating the layout support filter and tweaking for this purpose. Have it generate the classname and enqueue the styles to the block supports stylesheet, similar to the core filter, just instead of manipulating the markup it's all done in render_block_data, so the classname gets added to the block's props, which would be available then when rendering the fields as shortcodes.

That last thought bubble is only floated as a temporary option until core changes could be made to make this sort of thing more flexible/achievable.

I'd be happy to dig around there if the div option doesn't pan out and it helps.

The wrapper idea didn't work out. We can get the generated classname from the div, but then the difficulty is injecting that back into the shortcode, which is still in it's serialized shortcode form in the rendered markup at that point. So it requires parsing the shortcode again, injecting the class, and re-assembling it. Way too arduous.

A more far-fetched version would be almost duplicating the layout support

This is the idea that I'm settling on. The code for the child layout styles is fairly short, there are only a handful of css properties that it deals with, so it's not much, and it probably won't change much in core in the near future.