Forms: add layout support

[simison]

Forms currently has flex CSS styles, causing issues or making it complicated to design variety of layouts horizontally/vertically.

• Forms: stack form fields and submit button by default #41265 (comment)
• Forms: Fix html block rendering inside the form by wrapping the block #41269 (comment)

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.

[github-actions]

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.

[github-actions]

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?

[talldan]

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.

[simison]

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.

[simison]

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

[talldan]

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).

[talldan]

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:

jetpack/projects/packages/forms/src/blocks/contact-form/editor.scss

Lines 75 to 78 in 6c988c6

	&.jetpack-field__width-50 {
	flex: 1 1 calc( 50% - calc(var(--wp--style--block-gap, 1.5rem) * 1) );
	max-width: 50%;
	}

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:

jetpack/projects/packages/forms/src/blocks/contact-form/editor.scss

Lines 56 to 58 in 6c988c6

	&.wp-block-jetpack-button {
	flex-basis: auto;
	}

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.

[talldan]

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

[aaronrobertshaw]

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.