Contextual Block Padding (Spacing) Controls

[richtabor]

What problem does this address?

As the block content area is the primary level of interaction, let's consider exploring how we could empower site publishers to design with contextual spacing controls within the blocks themselves.

• This could work for padding, and probably margin as well.
• We could implement keyboard shortcuts for modifying X/Y/all values at a time (similar to Figma/Photoshop/etc).

What is your proposed solution?

Having a hover area the size of the current padding, that can be dragged to a specific size. The existing control within the Spacing PanelBody should reflect the changes. I should be able to utilize keyboard shortcuts to drag both X values at a time, or both Y values, or even all values.

I drew up some explorations below for us to maybe jive on if we're down.

Video:

padding.mp4

Screenshots:

Prototype:

https://www.figma.com/proto/ETa2dTgPUjltCOEQNnceUI/Gutenberg-Explorations?page-id=14%3A2&node-id=17%3A15&viewport=1634%2C2708%2C1&scaling=min-zoom

[karmatosed]

I really like this idea. Specifically, I like that it fits into a flow of someone interacting using the keyboard because it's a power feature accessed through a power command (using key combination). This means it's out of the way for many - which feels even better.

[mtias]

Just referencing that a similar treatment is currently in place for the Cover block. It needs to be refined and rolled out to the other blocks that support padding.

Screeny.Video.8.Jul.2021.at.11.54.59.mov

[paaljoachim]

It seems that the initial approach is getting the similar treatment that is now in place for the Cover block into other blocks. Then we can begin looking at how to make the approach contain a more practical visual and interaction.

[fwazeter]

Slack Discussion Thread on the Topic.

Overall thoughts are that having a visual way, possibly with short cut keys, to adjust margin/padding would enhance the user experience with content editing.

My commentary:

I think as a general design pattern, that having the text input areas available is necessary for obvious reasons. That said, they fall short in two places:

1. As a developer, it almost ends up faster to just make those changes in a stylesheet / in code directly, so in doing agency work, you almost always feel slower having to input stuff on an editor in text fields.
2. They're not always intuitively findable by a user, even one with experience with the platform (and easy to forget about).

Spacing is almost always one of those annoying "gotchas" when trying to have a uniform layout across a site.

Having a visual way to edit things, like the proposal, feels faster to use and allows for easier visual representation of spacing between elements. Plus, for end users, visual mechanisms tend to almost always be viewed as simpler to use / manage / edit.

Joyously made the great point that spacing being one of the most common gotchas is the reason why a user shouldn't have access to change it.

It's a good point and is similar to how users will break accessibility/content hierarchy by using a different header tag because they want font size to be larger or smaller.

The general thought to address that is to have it as an option that's enabled via global styles / settings, so that theme authors could make the decision on what they allow or not, with the thinking that eventually there will likely be a way for site admins to have settings available to them, but not available / locked for other users.

[mtias]

Closing as done in #40505.