Local block appearance controls should reflect values from global styles / theme.json

[jameskoster]

Current implementation

My theme.json declares a text color for h2s like so:

"color": {
    "text": "var(--wp--preset--color--grey-light)"
}

When I select a h2 in the Editor and open the color panel, I see this:

The canvas is telling me one thing, but the control is telling my something else. I can clearly see that a color is set, but the 🚫 icon in the control makes it look like no color is set. When I open the color picker, the transparent texture confuses things further by suggesting that the color is set to transparent. This combines to erode my confidence on what will actually appear on the frontend.

Expectation

My expectation would be to see something like this, where the control reflects the code exactly:

Suggestion

We show all values that are inherited from theme.json / Global Styles. Here's an example showing the Button block as styled globally, showing its values — colors, font size, padding, radius — in the inspector even locally.

• Color: show the value directly in the color panel, instead of the "unset" color. In the flyout, show the transparent grid to indicate an unset color, but show below that the inherited color, in the format of "[Source]: [Color-name]". For starters, "Styles" is suffient as a source.
• Typography: Show the inherited value as a gray ghost.
• Sliders: Show the inherited value as a gray ghost.
• Input values (border, radius, etc), show the inherited values as placeholder text.

This would be a first stap that doesn't necessarily preclude further steps taken in #49278 to visualize where the inheritance is coming from, but it might also reduce the issue enough that it'd be less urgent, perhaps even irrelevant. It would also make clearer when the contrast notice appears or doesn't; at the moment the values compared for contrast are not aware of inheritance, but with this change they could be made to.

Issue updated Aug 1, 2024.

[jasmussen]

I kind of like the idea that we're connecting "Styles" here. Perhaps in a future iteration we could link to the relative style in global styles even.

I like the visual, the simplification, and the overall reduction. I also understand your motivation: inheritance is pretty complex: how much do we need to explain?

That said, I feel like there may be a best of both worlds between your alt (which with its implied transparency gets close), and the more verbose version that literally spells out: "Inherited". Mainly: if you've opened the flyout, you're in the color customization flow, and there's room to actually show these values. Is there a way we can include the word inherited" somehow, yet still lean more simple? Perhaps just a suffix, or helper text on line 2?

[richtabor]

I'm not convinced "inherited" means something to most folks. Inherited from somewhere else? Where?

I was trying to find a way to connect that this color is derived from somewhere else, by prefixing "Styles".

[jameskoster]

I agree that the source of the inheritance will be important down the road. I don't know if it's necessary for a v1 of this, though?

[richtabor]

Could the source be something other than the global styles?

[fabiankaegy]

Could the source be something other than the global styles?

Section styles maybe? 🤔

[jameskoster]

Also maybe page-level or template-level styles in the future.

[jasmussen]

Initially it was the "Styles/Accent 1" that didn't gel with me. That sounded like the name of a single color. But the idea of the prefix works, so maybe it's just a visual thing: "Styles: Accent 1", perhaps with "Styles" in light gray?

Can even start there, and then see if we need further clarification, and then ambiguate into "Global styles:" and "Section styles:" as proposed.

[richtabor]

"Styles: Accent 1", perhaps with "Styles" in light gray?

Let's try it, to get this moving.

[jasmussen]

Alright folks, based on the last few items in this conversation, I've again updated the mockups (here in Figma) based on the latest. I've also updated the issue itself to reflect this, and in the spirit of getting this in motion for 6.7, going to now swap out the labels.

[ramonjd]

I've been meddling in this area while working on background image values, and noted some technical implementation details/questions.

I'm adding them here for reference.

• In the editor, block style control components need to know about "inherited" styles. This could be done in BlockStyleControls.
• Merged global styles settings, styles and other related properties are accessible in the block editor settings object, and therefore available in post/site editor contexts. The properties themselves are fairly disparate, __experimentalFeatures (settings), globalStylesData (styles) and so on. Probably room to consolidate them here.
• These "inherited" styles to be passed to the block controls include not only merged base, theme.json + global styles, but also inherited style variations, element styles (any others?). I suppose WordPress will need some hook to fetch, merge and reconcile the hierarchy here.
• Some inherited values need to be "resolved", the common example is a "ref" value in theme.json that refers to another value in the theme.json tree.
• Resetting a block control's values will restore them to the inherited values. What about "removing" styles? Should a user allow unsetting inherited styles?
• There are cases where a block needs to refer to its inherited settings/styles on the frontend, for example, using wp_get_global_styles() or wp_get_global_settings() in order to render its local classnames/styles. Layout does this already to some extent.

[jasmussen]

Resetting a block control's values will restore them to the inherited values. What about "removing" styles? Should a user allow unsetting inherited styles?

Yes, but this is a UI challenge that's already present in the block editor, in fact showing the inheritance is a first step to helping make it clearer where you might be able to unset an inherited style. One common place where we've solved it is inherited text case, where we added a value for the default (the minus) here:

[eirichmond]

"Styles: Accent 1", perhaps with "Styles" in light gray?

Let's try it, to get this moving.

Could it be simplified further with just "Core", "Theme", "Global" or "Block" ?

[richtabor]

Could it be simplified further with just "Core", "Theme", "Global" or "Block" ?

All that matters is that this is inherited; that this color is not applied at the block level. Whether or not it's a core, global, or theme color is not relevant—perhaps even confusing. I was suggesting "Styles" as it's the UI source for all styles.

[eirichmond]

Could it be simplified further with just "Core", "Theme", "Global" or "Block" ?

All that matters is that this is inherited; that this color is not applied at the block level. Whether or not it's a core, global, or theme color is not relevant—perhaps even confusing. I was suggesting "Styles" as it's the UI source for all styles.

Thats a fair point and I agree—I see your point about "Styles" being a good starting point. However, this brings up a broader conversation from a developer's perspective. For me, these distinctions (Core, Theme (or Styles 😇 ), Global or Block) are relevant and, at times, can be confusing.

For example, in core, the blockGap is set to 24px, but in the UI, it appears as 0px until you interact with it. To maintain the original core look, the user has to manually set it to 'X-Small' at the block level. Displaying something like "Core, Styles, Global, or Block" could help reduce confusion from a development standpoint, in my opinion.

I’ve attached an example with three columns to illustrate how blockGap interaction works. The same issue occurs with the button outline variation, where the border is set to 2px but isn't shown in the UI.

Apologies if this is somewhat tangential to the original issue, but I believe it's related. Probably more relevant to #49278

[ramonjd]

We've started looking at representing a block's inherited values in the controls in this tracking issue:

• https://github.com/WordPress/gutenberg/issues/64670

Feedback/ideas are welcome, though it's early days 😄 and there's nothing yet to test.

Initially, the work will be focussed on drilling through theme.json/global styles data arrive at the right value.

For example, assuming only theme.json/global styles as a source, a block could inherit from:

• top-level styles
• user global styles (the custom post type content)
• element styles
• block styles
• block style variations

I'm not any of these labels are helpful to someone who just wants to style a block, unless, it's a theme developer wishing to know where the inherited styles are coming from (?)

Thanks!