Discuss the default scope of each block's properties

[MaggieCabrera]

Following up with #27295, this issue is to discuss where each style property should be visible to the user.

The options would be (see #28163):

• "all": the UI control is shown everywhere
• "block": the UI control is only shown in the block sidebar
• "global": the UI control is only shown in the global sidebar at the site editor
• "none": the UI control is no shown anywhere

Colors

Block	Text	Background	Gradient	Link
root
core/button
core/columns
core/cover
core/group
core/heading
core/list
core/media-text
core/paragraph
core/post-author
core/post-comments
core/post-comments-count
core/post-comments-form
core/post-content
core/post-date
core/post-excerpt
core/post-tags
core/post-title
core/pullquote
core/quote
core/site-tagline
core/site-title

Typography

Block	Font Size	Font Family	Font Weight	Line Height
root
core/button
core/columns
core/cover
core/group
core/heading
core/list
core/media-text
core/paragraph
core/post-author
core/post-comments
core/post-comments-count
core/post-comments-form
core/post-content
core/post-date
core/post-excerpt
core/post-tags
core/post-title
core/pullquote
core/quote
core/site-tagline
core/site-title

Spacing

Block	Margin	Padding
root
core/button
core/columns
core/cover
core/group
core/heading
core/list
core/media-text
core/paragraph
core/post-author
core/post-comments
core/post-comments-count
core/post-comments-form
core/post-content
core/post-date
core/post-excerpt
core/post-tags
core/post-title
core/pullquote
core/quote
core/site-tagline
core/site-title

@nosolosw

[pbking]

I would also argue that "border styles" (width, color, radius, style) should also be something that we consider mapping the default availability for.

While we don't have user-facing controls for those attributes yet they are forthcoming.

[carolinan]

Before I forget, the comments blocks mentioned above needs to be split down to the individual blocks.
How do you select line height for a core/post-comments-form that includes several elements? :)

[beafialho]

As a designer user, I believe it should be possible to customize a theme globally. Having all these options available for every block may turn into a confusing experience. I usually choose a theme for its main structure or specific patterns and then wish to customize font properties, colors and spacing, but this is something I do when building a site, not in every block. Just wanted to add my perspective here, but I'd love to know your thoughts on which occasions a user would want to see these options in the "block" sidebar.

[jasmussen]

If I understand this issue correctly, the ultimate goal is to provide a matrix for when a theme feature or design tool (such as letter-spacing) is available in code, in global styles, on a per-block basis, or a combination of those. Is that correct?

In that vein, I share Bea's instinct: the more that is available in global styles, for themers to configure, the better. And on the other side of the spectrum, not all of what is available there can be shown by default on every block out there, the experience would not be great.

In #27331, an effort has been put into finding a way to bridge those two: allowing a plethora of design tools to be available, finding a good subset of those to show by default, all the while still making them potentially available on a per-block basis if you really really need them.

This image shows perhaps the best example of that spectrum, with a default user experience on the left, and the full range of tools on the right:

The effort to discuss which controls are valuable in which blocks is definitely still relevant, and I hope that the above ticket can help inspire good defaults as well!

[lukecarbis]

+1 to many thoughts from @jasmussen.

The goal of the Post Editor is to craft content. Complicated design features should try to stay out of the way.

The goal of global styles is to set the design features of a site. All design features should try to be prominent.

In general, most blocks should share the same level of customisation, so the user knows what to expect. I think this strikes a pretty good balance:

Block level settings:

• Text colour
• Background colour (including gradient)
• Font size
• Font weight

Global styles:

• Text colour
• Background colour (including gradient)
• Link colour
• Font family
• Font size
• Font weight
• Line height
• Margin
• Padding

[oandregal]

👋 When we created #27295 the views on how this all should work were different. The current view is that:

• Themes can use any style property in theme.json for any block, whether or not the block declares support for it. See conversation at Custom controls, block supports, and theme.json #29778 (comment) (not implemented yet).
• In terms of UI control:
  • a block exposes some UI tools (via block supports or by creating custom controls)
  • a theme can express their preferences via theme.json and there will be no difference between post editor & site editor: if a theme says no customColors, they won't be shown anywhere.
  • There are some things already supported in theme.json for this. We can add more as needed. I presume this will be a slow area until the sidebar re-design is finalized, at which time we may need to revisit what we have.

This issue can still be open if you feel it provides value, but I thought I share the new direction in case it makes think this should be closed.