Styles: show a hierarchy of styles clearly (theme, user, global unspecific, global specific, local, etc)

[annezazu]

When no styles are detected

When styles cannot be detected (from a style provider like global styles / theme.json) no controls are displayed. This eliminates the confusion between undetectable inherited styles (e.g. custom css, browser styles) and empty/unset controls. See #43082 for additional context.

Working globally

Respecting the convention above, panels are empty until a value is set (either in the UI, or via theme.json).

Working locally

When working locally there are three states to consider:

Inherited values

If a value is inherited (e.g. from global styles) the control displays that value, and the label has a purple accent denoting the global context. Hovering/focussing the label reveals the source in a tooltip. The control cannot be removed because if there's no local setting, the inherited value will be used.

Local overrides

If an inherited value is changed then a blue dot is appended to the label. Clicking the dot reveals a menu where the user can reset to the global default, or push the value upstream. Some controls (like background image, see below) may need an additional action to 'unset' the value locally.

Local styles
Styles can be added to a block in the local context that have no inherited value. The manifestation of this in the UI is essentially the same as the "Working globally" case above:

With one caveat: If a global style for this property is later added, the local control would then exhibit the blue dot.

Examples

In addition to the block-spacing example above, here are a couple others that have come up in other issues recently. In each case the edit context is local to a document:

Lightbox

Background image

Breakdown

This doesn't all need to be implemented at once. The work could be broken down into the following steps:

• Local block appearance controls should reflect values from global styles / theme.json #37752
• If local styles override global then indicate that change with a dot which serves as a Reset affordance.
• Highlight where those styles are coming from.
• Implement make default/push to global functionality.

Important note

The purple accents used to indicate inherited styles in the mockups above could be a bit heavy-handed in practise. We should continue to explore other design solutions for this.

Original issue

Knowing what style is affecting something on a theme is difficult (is it a global element? is it coming from a block type? is it local to the template?). This has shown up in a few areas already, from Custom CSS https://github.com//issues/47946 to the general experience of conflicting styles https://github.com//issues/45086 https://github.com//issues/44931. To improve this, we should find a way to show a hierarchy of styles clearly (theme, user, global unspecific, global specific, local, etc). While building this, we should also consider ways to push or transfer something to the right level when working through a design, which relates to https://github.com//issues/44931

In most cases understanding this style hierarchy is not crucial, as you can accomplish most of what you need to without the visualization. You go to global styles to style site wide, you edit pages to style locally. Nevertheless for more complex sessions, it can be useful to surface, but due to the rarity of needing to surface this, the footprint and UI weight of any visualization feature needs to be small.

Here's a take that makes the design tool label clickable to reveal the inheritance:

• Click a label to see the inheritance
• If the popover has a link, that link should serve as a deep-link to the origin of the inheritance

For this concept to work, the Color flyout has received its own label.

Thoughts?

[jasmussen]

As an example of style inheritance reflected in a few ways:

• If no font is set in global styles, it inherits Times New Roman from the browser stylesheet (though I think we may have overridden that to system fonts)
• If "Crimson Pro" is set as a global font, then a group inherits that. But a group can also further set its own font inside, such as DM Sans.
• Subsequent nested groups could keep at this, creating a deep inheritance hierarchy, i.e. Group ← Group ← Group ← Global Styles ← Browse styles.

The added nuance here is that in the block editor, we are talking not just about CSS inheritance, but also about global styles inheritance, such as inherited content/wide widths. And even further, you might set a block default in Global Styles > Blocks, and then override it locally in a post. In the future you might even set ref'ed colors (Set the background color of this button to the same color as the global text color).

Finally, there's theme inheritance. You might activate a block theme that has a default root padding. You might then create your own style variation of that, which has its own root padding. It needs here to be visualized that your style variation is replacing root padding values that exist in theme.json.

Sharing these examples as context for a design that tackles this, that ideally such a design can tackle these, while still being minimalistic, and perhap ideally with a way to navigate to each origin.

Related:

• Design tools: Better handling of unset / inherited values #43082
• Local block appearance controls should reflect values from global styles / theme.json #37752

[jasmussen]

I ended up creating #50659 instead of updating this one. I'm happy to close the other one and use this one? Let me know.

[annezazu]

It might seem silly but I've linked to this one a fair amount. Mind closing yours and sharing the designs here?