Forms: modernize use of global style controls

[simison]

Sidebar for each field is quite busy, and we're missing some basic styling controls. Let's update each field to rely on declared block support for global styles and expand on options.

Note spacing issue bug visible in the screenshot.

Button block is better example:

List of design tools missing at form level:

• Alignments: left/right/center (supports.align)
• Buttons styling at form level (supports.color.button)
• Spacing: block gap (supports.layout)
• Layout controls? (supports.layout)
• Typography controls at form level vs fields; consider if needed. (supports.typography)

Text fields

Note form elements missing in theme.json

• Missing:
  • Placeholder color
  • Shadows
  • Padding/margin
• Exists but not via supports:
  • Typography (stable and experimental features)
  • Color

[aaronrobertshaw]

Sidebar for each field is quite busy

Adopting core block supports or rendering controls to their slots would trigger the display of the tabs in the block inspector sidebar. That might lessen the burden on the current sidebar's real estate.

I'm not sure but the block inspector's style tab may not support custom panels being rendered within it. If that limitation is confirmed, it could be a blocker to making this less busy via those tabs.

Let's update each field to rely on declared block support for global styles and expand on options.

This will be easier said than done with the way field blocks currently try to juggle two sets of styles, one each for the label and input. More details in the wall of text notes to come 🙂

Buttons styling at form level (supports.color.button)

There are some edge cases around styling elements via global styles instead of block types. Depending on how some blocks are styled the direct targeting of the button element can mean the style's proximity causes it to override other styles applied on the parent that have more specificity.

This isn't to say it can't be done, only that it will need some thorough testing and possibly some extra styling tweaks to the block.

Layout controls? (supports.layout)

Layout block support might require a re-think of the current form field width controls and styles. There's also some work underway in Gutenberg around the Grid layout support. This might provide a smoother pathway to migrating current Form blocks over to block supports in terms of layout.

---

I spent some time today trying to get a little extra context around Forms and all the available blocks, their current settings/styles and what block supports we might be able to migrate to or adopt.

The following are notes on general issues I found. I'm out of time today but will soon create issues for those that haven't already been reported and tracked.

Bugs

• The Outline block style variation for the button block doesn't apply properly in the contact form.
  • In the editor it's missing the outline/border.
  • On the frontend, the outline styles seem to be overridden by default block type styles from the theme
  • The premium content block's editor styles break the Outline block style for the button in Forms
  • Issue: Contact Form: Submit button not reflecting selected styles (Outline) on several themes #40432
  • PR: Jetpack button: implement outline style #41194
• Existing align support (e.g. wide/full block alignments) doesn't work in the editor due to a wrapping div that's in the editor markup.
  • Issue: Forms: Alignment options do not work in the editor #41202
• labelLineHeight and other styles can end up as an empty string value within the block attributes
  • Issue: Forms: Clearing styles results in empty string values in block attributes #41204
  • PR: Forms: Prevent empty string values in block attributes for field styles  #41206
• Most of the controls (except Colors which use the ToolsPanel component) can't effectively be reset
  • Even if we can't use core block supports, perhaps using ToolsPanel components would make it easier to reset values to whatever their default should be. This will be more important if things can be style by Global Styles.
  • For the font size control I had to click the custom value toggle, then delete the value from the input to reset that
  • It was worse for the border width and radius controls. Clearing the input field wouldn't reset the value from internal state so I had to know or guess what the original value was or check the revisions and parse the answer from that.
  • Issue: Forms: Can't easily reset style values other than colors #41205

Styling Related Issues

• It seems a bit weird to split up the border controls especially color and width
• Not leveraging core's border support means only simple borders are supported.
  • Adopting core's border support would allow different borders per side and different radii per corner.
  • As the border is only applied to the input of field blocks, the Block Selectors API could be leveraged to target the styles to the inner element when using global styles and manually applied in the edit component at the block instance level (core Image block is an example of this)
• The syncing of styles across other sibling blocks was really surprising. Without any real history here this seems like styles that should be on the parent and then overridden as required where individual block instances are desired to differ.
  • The proposed adoption of typography supports in PRs like Forms: add button color and typography global style controls #41141 are a step in this direction.
• The fact that most "field" blocks are really a flattened combination of two inner blocks (hypothetical label & input blocks) means they need to cover two sets of styles.
  • This isn't a scenario supported by Global Styles. One block type = one set of styles.
  • Even adopting typography support at the Form level might not help that much.
  • Styling generally at the Form level and overriding at the block instance level for exceptions seems to align more with core (and my personal expectations FWIW)
  • Has there been any investigation into refactoring the form field blocks into essentially containers for two inner blocks e.g. Label and Input?
    • This would allow global styles and block supports to work as you'd expect e.g. style the Label block via global styles and select and override styles on specific block instances as desired.
• Nit: With the default styling of the dropdown select in the editor I was initially expecting a custom select field with matching styles on the frontend.

Non Styling Issues

• The color panel being the only one using the ToolsPanel component seems odd.
  • Inconsistency aside, it shows the user a possible way to reset controls via the ellipsis menu only for that "feature" to be missing on panels right below it.
• Dragging blocks within the Form block is really rough, especially the Button block.
  • You can move the Button block via the block movers in the toolbar but dragging it doesn't seem to offer any valid drop locations.
  • Dropping the button seems to move it to the top of the current parent block.
• The form related blocks being duplicated across "Forms" and "Jetpack" in the main block inserter seems off and possibly overwhelming for users