Section specific Theme.json

[jorgefilipecosta]

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

[Humanify-nl]

Happy to see this, theme.json not cascading like CSS has been weird!

Cascade
I’m all for making theme.json behave as close to css practices as possible. It is often what is expected from perspective of developers diving into Gutenberg for the first time, and it makes a lot of sense.

I’d like to propose adding font sizes as well to this (see e.g. #39277)

Sectioned content
One of the major problems in writing customized css is not being able to know (dynamically) if a group is a direct child of root-container and as such a section. I have to determine this by e.g. it’s position , if it’s full width, writing complex selectors. Same goes for determining if two section both have background color, and how to remove margins vertically on those conditions.

Then came template parts, who seem to become the same thing, but do NOT play nice with the ‘main groups’.

Will there be any plans to ‘set a group as section’? Or even a dedicated section block? I feel template parts and sections should ultimately be close to the same thing in terms of DOM output. Because they create highly sectioned and thematically (and in terms of content) similar areas that are interchangeable.

[oandregal]

Miguel and I started looking into this and prepared #40547 I've updated the issue description with a preliminary list of tasks.

[oandregal]

We aim to introduce a new source for settings (& partially to styles), in addition to what we already use, the core/block-editor store. How do they should work together?

Let's take a given setting, say color.palette, and unwrap how it should work for a children of the section. I see two alternatives

By source algorithm (settings coming from block attributes first, settings coming from the block editor store later):

1. blockAttributes.settings.blocks.blockType.color.palette
2. blockAttributes.settings.color.palette
3. store.settings.blocks.blockType.color.palette
4. store.settings.color.palette

By context algorithm (settings for the block first, settings for the global later - disregarding what the source is):

1. blockAttributes.settings.blocks.blockType.color.palette
2. store.settings.blocks.blockType.color.palette
3. blockAttributes.settings.color.palette
4. store.settings.color.palette

For settings, the "by source" algorithm works best. This allows us to do things like this easily:

• Set a different palette for this pattern and all its children:
  • by source: a single setting blockAttributes.settings.color.palette
  • by context, you need to address every inner block individually in addition to the section itself, using the same values:
    • blockAttributes.settings.color.palette (for the section itselt)
    • blockAttributes.settings.blocks.paragraph.color.palette (for any paragraph children)
    • blockAttributes.settings.blocks.list.color.palette (for any list children)
    • etc
• Lock-in the ability to add custom font sizes in the section:
  • by source: blockAttributes.settings.typography.customFontSize
  • by context, you need to address every inner block individually, in addition to the section itself:
    • blockAttributes.settings.color.palette (for the section itselt)
    • blockAttributes.settings.blocks.paragraph.color.palette (for any paragraph children)
    • blockAttributes.settings.blocks.list.color.palette (for any list children)
    • etc

For "styles", it doesn't matter which algorithm we use because they don't cascade (the top-level styles are attached to the "section", they're not used to fill the block styles):

• Set a background color for the section: only addressable by blockAttributes.styles.color.background.
• Set a text color for all the paragraphs within: only addressable by blockAttributes.styles.blocks.paragraph.color.text.

I think the "by source algorithm" is a better representation of what we want to achieve: that sections become the source of truth for configuring whatever is within.

[oandregal]

Another detail is: if the section is a group block and it has the following settings:

{
  "settings": {
    "color": {
      "link": true
    },
    "blocks": {
      "core/group": {
        "color": {
          "link": false
        }
      }
    }
  }
}

The link color should be disabled for any group that is a children of the section. But, given the section is a group itself, what its behavior should be?

I think the link should be enabled. This is, the settings.blocks only affect the children of the section but not the section itself.

[luisherranz]

I was reading your conversation on #40547 (comment), but as that PR is already merged, I'll answer here 🙂

Have you considered going with the by context algorithm but adding the ability to change all blocks at once with "*"?

@oandregal, in your example of #40547 (comment), instead of doing this to disable the typography settings of all the blocks (even the ones that have been explicitly configured)

{
  "settings": {
    "typography": {
      "customFontSize": false,
      "dropCap": false,
      "fontSizes": [],
      "fontStyle": false,
      "fontWeight": false,
      "letterSpacing": false,
      "lineHeight": false,
      "textDecoration": false,
      "textTransform": false
    }
  }
}

you would do this:

{
  "settings": {
    "blocks": {
      "*": {
        "typography": {
          "customFontSize": false,
          "dropCap": false,
          "fontSizes": [],
          "fontStyle": false,
          "fontWeight": false,
          "letterSpacing": false,
          "lineHeight": false,
          "textDecoration": false,
          "textTransform": false
        }
      }
    }
  }
}

That is saying, "I want to overwrite the explicit settings of all the blocks".

That way, it's easy to overwrite both the global settings and the explicit block settings.

[mtias]

Noting that this is also related to #27233.

[adamziel]

Related: WordPress/wordpress-develop#2853 adds support for array-based style property in block.json. For example:

{
	// ...
	"style": [
		"wp-block-button",
		{
			"border": {
				"//": "100% causes an oval, but any explicit but really high value retains the pill shape.",
				"radius": "9999px"
			},
			"color": {
				"text": "#fff",
				"background": "#32373c"
			}
		}
	}
}

[SaxonF]

Summarising one of main the problems we're trying to solve here:

When designing the sections of a page (or even entire pages/templates) you often want to vary outside the default element styling of your site (e.g. a dark section with light text). To do this currently you need to manually set background and text colour each and every time and there are gaps in what you can control within a section (e.g.buttons). This project aims to solve that pain point by allowing you to create sets of styles that can be applied to sections or even entire pages.

Here's an initial exploration that combines rethinking the global styles IA with some previous explorations around colour sets. We're extending the idea of colour sets to all styles.

element-variations.mp4

Note that we'd include element selection within the page/template inspector as well so you can style entire pages.

There are a couple of trade-offs that come with this work that would be worth discussing.

• It adds complexity as we now have themes, presets, style variations, block variations, element variations (or whatever we call this). That's a lot and possibly overwhelming.
• Switching themes we'd have to revert sections back to default variations
• With the solution proposed here we'd have to ship this first

@WordPress/gutenberg-design

[SaxonF]

We have #53667 for 6.4 which offers a valuable starting point that might lead to colour/style sets seen above or element styling beyond colours.

[annezazu]

Moving this out of "done" as that's for fully completed work and #53667 is already listed there. Moving this to 6.5 instead.

[richtabor]

We have #53667 for 6.4 which offers a valuable starting point that might lead to colour/style sets seen above or element styling beyond colours.

Which will be much more empowering imo — even if only theme.json to start with.

[aaronrobertshaw]

A draft proof of concept for this feature for WP 6.5 is up in #56234.

It is only intended as a first step towards covering both section-specific styling and element color sets. An earlier exploration looked at storing the section styles within the block instance's style attribute however it was suggested that it instead be stored within Global Styles to facilitate re-use.

To limit the scope such that it is achievable for 6.5, #56234 is code-only except for a minimal UI to apply a section style to a block instance. Future follow-ups post 6.5 should include updating Global Styles to allow user-created section styles as well as the ability to push a block instance’s styles to Global Styles as a section style.