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

Contextual Block Padding (Spacing) Controls #33221

Open
Tracked in #33447
richtabor opened this issue Jul 6, 2021 · 4 comments
Open
Tracked in #33447

Contextual Block Padding (Spacing) Controls #33221

richtabor opened this issue Jul 6, 2021 · 4 comments

Comments

@richtabor
Copy link
Contributor

@richtabor richtabor commented Jul 6, 2021

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:

Screen Shot 2021-07-06 at 10 20 33 AM

Screen Shot 2021-07-06 at 10 20 46 AM

Screen Shot 2021-07-06 at 10 20 58 AM

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
Copy link
Member

@karmatosed karmatosed commented Jul 7, 2021

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
Copy link
Contributor

@mtias mtias commented Jul 8, 2021

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
Copy link
Contributor

@paaljoachim paaljoachim commented Aug 24, 2021

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
Copy link
Member

@fwazeter fwazeter commented Aug 24, 2021

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
5 participants