Part of: #39281

We already allow a block to have the style object of theme.json, but for now, we only accept styles affecting the block itself, not its descendants. E.g., in the group, we can not say the text color of paragraphs nested inside them is X.

We don’t have a settings object, so we can not say the color palette for this section is Y.

This task is about expanding the style shape to support everything theme.json does and a new settings object.

Although the implementation of the settings should be ready to support every setting, I guess we can lock it down at the start to change the color palette and allow to totally disable colors so patterns can provide a more locked experience inside them. I’m not totally sure if we should support every setting so having an initial locked implementation makes sense, and then we can progressively expand what we support and maybe even support everything if we find it makes sense.

There are multiple edge cases, e.g., the theme.json sets a palette specific to the paragraph block, and the section in a pattern sets a palette specific to pattern. A paragraph inside that pattern uses the color palette of the pattern or the global one of the paragraph?

I think the algorithm should be the block uses the closest style/setting specific to that block (first of the pattern than at the global) if there are no block particular values, it uses the closest global value. In the previous sample, it would use the global paragraph color.

In the first version, I expect that we can store styles and settings as just normal block attributes in the HTML comment blob like we do now for styles.

Tasks

Settings:

• Add settings hook #40547
• Render presets coming from the settings of a section #40683
• Add: Frontend section presets output #42124
• Clarify how translatable strings from settings defined in a block instance can be made translatable. The only ones at the moment are preset names (color, font size, and font family).
• Allow settings to be changed by the user via UI.

Styles:

• Block type styles: create a blocks section to hold and render them, ala theme.json.
• Expose UI to users.
• Absorb named attributes into the style object, e.g.: we should not store the font size value in fontSize if it's a preset value and in styles.typography,fontSize if it's a custom value. We should use the style object for everything. Do so without modifying how is serialized (to classes if it's a preset value and as inline styles if it's a custom one).
  • backgroundColor
  • borderColor
  • fontFamily
  • fontSize
  • gradient
  • textColor