Block Editor: Reflect inherited Global Styles values in block inspector controls

[aaronrobertshaw]

Closes: #77595

What?

Inspector controls now reflect the Global Styles values a block inherits, so the panels line up closer to what you actually see on the block in the canvas.

• No local value with inherited value:
  • the control shows the inherited value at rest via a placeholder, preselected option, or resolved value, depending on the control
  • it will have a dotted underline on the label to mark it as inherited
• Local value over an inherited one:
  • an override indicator appears on the label as a small blue dot
  • the blue dot turns into a Reset to inherited value button on hover/focus
  • clicking the blue dot reset button clears the local override (a single undo) to fall back to the inherited value
• No inherited value:
  • no override indicator will show, it only appears when there's an inherited value to override
  • normal control and panel reset behaviour has been kept

Inherited global styles values only come from the merged Global Styles data:

• theme.json
• user global styles edits
• the block type global styles
• a block style variation applied directly to the block

There are no computed styles involved, so custom CSS, enqueued stylesheets, and ancestor variations still can't be reflected even though they paint the canvas.

Scoped to an MVP

To land the core of this in 7.1 without first having to extend heavily-used @wordpress/components (like BaseControl) to accept injected label nodes and settle the related design and portal questions that come with it. Two things are deliberately out of scope here and moved to follow-ups:

• The portalled label adornment and the "inherited from…" path tooltip. Marking where a value is inherited from needs an adornment in side the control label, but neither BaseControl nor InputControl exposes one today. Rather than push that public-API change through now, this PR keeps only the dotted underline at rest and moves the portaled adornment + path tooltip to a follow-up, where the approach and design can be settled properly.
• Pushing an individual block style up to Global Styles. The design direction from the issue (#77595 / #49278) is now its own feature in #79839. This is still hopeful for 7.1, just tracked separately.

Why?

Right now a control only reflects what's set on the block, never what it inherits.

A Paragraph block renders with the theme's colour, size, and padding on the canvas while the controls sit empty, reading as "unset" when they're anything but. You can't tell a local override apart from an inherited value.

It's a long-standing rough edge (#37752, #43082, #49278), tracked under #77595.

How?

• A single function, buildInheritedValue, merges the value a block inherits in precedence order; theme.json/user defaults ‹ block type ‹ applied block style variation. It's pure: all value resolution ({ ref } envelopes and theme-file image links) happens here.
• The block support hooks (background, border, dimensions, duotone, typography, elements) read the Global Styles data via useInheritedValue, resolve the cascade for the selected block, and pass the result to the shared inspector panels as a prop.
• The panels stay presentational. They render the value at rest, mark the control as inherited or overridden, and wire up the reset. They have no store access, so they remain liftable out of block-editor.
• 0 is preserved, inherited values aren't saved until a user picks them, and reset stays a single undo.
• The inherited underline and the override dot/reset render inline as label siblings, no portal.
• The canvas is untouched. Rendering still relies on the normal CSS cascade, so this is display-only.

Architecture

The flow is a straight line from the store to the control:

1. Block support hooks (background, border, dimensions, duotone, typography, elements) own the wiring for each control group. Through useInheritedValue, they read the merged Global Styles data (and theme-file links) from the store in a single useSelect, then call build InheritedValue to resolve the Root ‹ Block ‹ Variation cascade for the selected block, dropping root-level values that don't actually cascade to it (e.g. a root background).
2. That resolved set of inherited styles is passed into the shared inspector panels as a prop.
3. The panels' controls use it to reflect the values currently applied to the block, inherited or local, and to indicate when a value is inherited (and, in the follow-up, show a tooltip with the inheritance breadcrumb).

So store access lives only in the hooks, cascade resolution lives only in the pure function, and the panels stay presentational. No data dependency and liftable out of block-editor.

APIs

• No new public APIs on this PR or the follow-up. A public API change would only be needed if we had to extend @wordpress/components (e.g. BaseControl) to wrap control labels in tooltips. This PR doesn't need that, and the follow-up avoids it too by portaling the adornment instead. Neither branch touches @wordpress/components.
• useInheritedValue and buildInheritedValue are internal to block-editor, not re-exported from the package entry or privateApis.
• The only change to the existing (already private) panels is one optional, backwards-compatible prop, showInheritanceLabelIndicators, which flags whether the inheritance labels and indicators should be shown. The inheritedValue prop is pre-existing.

Notes

• Builds on Block Supports: Relocate text and bg color controls to Typography and Background panels #77279 (now landed), which relocated the colour controls into the Typography and Background panels this threads through.

Testing Instructions

Inherited values

1. Select a block styled through Global Styles and open the inspector.
2. Confirm controls across Typography, Background, Elements, Dimensions, Border, and Filters show the inherited values at rest, each with the dotted-underline label, and that they match the canvas.
3. Check it holds for both preset values (colour slugs, font-size presets) and raw values.

Local overrides

1. Set a local value on an inherited control and confirm the blue override dot appears on the label.
2. Hover or focus the dot: it becomes a Reset to inherited value button. Activate it, the local value clears, the control falls back to the inherited value, and a single undo brings it back.

Edge cases

1. Confirm a 0 value is treated as a real value, not an empty one.
2. Confirm a plain local value with no inherited value behind it uses the normal panel reset, with no override dot.

Example theme.json

To help with defining global style values to check different controls the following theme.json might be of use. It is a modified version of the emptytheme theme.json, so applying this there and switching to emptytheme is a quick way to get up and running.

Example theme.json

{
	"$schema": "../../schemas/json/theme.json",
	"version": 3,
	"settings": {
		"appearanceTools": true,
		"typography": {
			"writingMode": true,
			"fontFamilies": [
				{
					"slug": "georgia",
					"name": "Georgia",
					"fontFamily": "Georgia, 'Times New Roman', serif"
				},
				{
					"slug": "system",
					"name": "System",
					"fontFamily": "system-ui, -apple-system, 'Segoe UI', Roboto, sans-serif"
				}
			]
		},
		"layout": {
			"contentSize": "840px",
			"wideSize": "1100px"
		}
	},
	"styles": {
		"blocks": {
			"core/paragraph": {
				"color": {
					"text": "#1e1e1e",
					"background": "#f6f7f7",
					"gradient": "linear-gradient(135deg, #fdfbfb 0%, #ebedee 100%)"
				},
				"typography": {
					"fontFamily": "var:preset|font-family|georgia",
					"fontSize": "1.125rem",
					"fontStyle": "italic",
					"fontWeight": "600",
					"lineHeight": "1.7",
					"letterSpacing": "0.01em",
					"textAlign": "justify",
					"textColumns": "2",
					"textDecoration": "underline",
					"textIndent": "1.5em",
					"textTransform": "capitalize"
				},
				"spacing": {
					"margin": {
						"top": "0",
						"right": "0",
						"bottom": "1.5rem",
						"left": "0"
					},
					"padding": {
						"top": "0.5rem",
						"right": "1rem",
						"bottom": "0.5rem",
						"left": "1rem"
					}
				},
				"border": {
					"color": "#e0e0e0",
					"style": "solid",
					"width": "1px",
					"radius": "4px"
				},
				"elements": {
					"link": {
						"color": {
							"text": "#0073aa"
						},
						":hover": {
							"color": {
								"text": "#005177"
							}
						}
					}
				}
			},
			"core/group": {
				"background": {
					"backgroundImage": {
						"url": "data:image/svg+xml;base64,PHN2ZyB4bWxucz0naHR0cDovL3d3dy53My5vcmcvMjAwMC9zdmcnIHdpZHRoPScyMDAnIGhlaWdodD0nMjAwJz48ZGVmcz48bGluZWFyR3JhZGllbnQgaWQ9J2cnIHgxPScwJyB5MT0nMCcgeDI9JzEnIHkyPScxJz48c3RvcCBvZmZzZXQ9JzAnIHN0b3AtY29sb3I9JyNjOWU3ZmYnLz48c3RvcCBvZmZzZXQ9JzAuNScgc3RvcC1jb2xvcj0nI2VhZTRmZicvPjxzdG9wIG9mZnNldD0nMScgc3RvcC1jb2xvcj0nI2ZmZDZlOCcvPjwvbGluZWFyR3JhZGllbnQ+PC9kZWZzPjxyZWN0IHdpZHRoPScyMDAnIGhlaWdodD0nMjAwJyBmaWxsPSd1cmwoI2cpJy8+PGNpcmNsZSBjeD0nNjAnIGN5PSc3MCcgcj0nMjgnIGZpbGw9JyNmZmZmZmYnIG9wYWNpdHk9JzAuMzUnLz48Y2lyY2xlIGN4PScxNTAnIGN5PScxNDAnIHI9JzQwJyBmaWxsPScjZmZmZmZmJyBvcGFjaXR5PScwLjI1Jy8+PC9zdmc+"
					},
					"backgroundSize": "cover",
					"backgroundPosition": "center center",
					"backgroundRepeat": "no-repeat",
					"backgroundAttachment": "fixed"
				},
				"color": {
					"text": "#1e1e1e",
					"background": "#ffffff",
					"gradient": "linear-gradient(135deg, #f6f7f7 0%, #e5f0f5 100%)"
				},
				"typography": {
					"fontFamily": "var:preset|font-family|system",
					"fontSize": "1rem",
					"fontStyle": "italic",
					"fontWeight": "500",
					"lineHeight": "1.6",
					"letterSpacing": "0.02em",
					"textDecoration": "underline",
					"textTransform": "uppercase"
				},
				"spacing": {
					"blockGap": "1.5rem",
					"margin": {
						"top": "2rem",
						"bottom": "2rem"
					},
					"padding": {
						"top": "2rem",
						"right": "2rem",
						"bottom": "2rem",
						"left": "2rem"
					}
				},
				"dimensions": {
					"minHeight": "120px",
					"minWidth": "200px"
				},
				"border": {
					"color": "#d5d5d5",
					"style": "solid",
					"width": "1px",
					"radius": "8px"
				},
				"elements": {
					"heading": {
						"color": {
							"text": "#0a1e2e"
						},
						"typography": {
							"fontWeight": "700",
							"lineHeight": "1.2"
						}
					},
					"button": {
						"color": {
							"text": "#ffffff",
							"background": "#0073aa"
						},
						"border": {
							"radius": "4px"
						},
						":hover": {
							"color": {
								"background": "#005177"
							}
						}
					},
					"link": {
						"color": {
							"text": "#0073aa"
						},
						":hover": {
							"color": {
								"text": "#005177"
							}
						}
					}
				}
			}
		}
	},
	"customTemplates": [
		{
			"name": "custom-template",
			"title": "Custom",
			"postTypes": [ "post" ]
		}
	],
	"patterns": [ "short-text-surrounded-by-round-images", "partner-logos" ]
}

[ramonjd]

I've given this a very quick test run and I really like that it's focussed on fixing the most immediate trust problem: the canvas shows a styled block, but the inspector controls say "empty".

The tooltips and reset button make it clear about where the styles come from too

Styles can come from anywhere, e.g., computed CSS, cascades, custom CSS, plugin styles etc etc, and it can get messy pretty quickly so in my mind, communicating this block-theme specific relationship (which is the only one we can really control) is important.

One question I had was whether "Inherited from Global Styles" feels helpful enough without saying "element", "block", or "variation". But now I think that's getting into the weeds.

Fundamentally, I want to know if this block is using the global value, what happens when I change it locally (now it is overriding), and how I can reset it back to the default inheritance. So I think you've covered the basic here in my opinion.

Nice work and thanks for getting a POC up for folks to play around with.

[aaronrobertshaw]

Thanks for the early feedback @ramonjd, appreciate it 🙇

One question I had was whether "Inherited from Global Styles" feels helpful enough without saying "element", "block", or "variation". But now I think that's getting into the weeds.

This is on the cards to investigate but ensuring we can accurately trace where the inheritance comes from and then also pass that data along to the tooltip being injected into the DOM was another. So I left that to follow-up iterations that I'm in the process of exploring.

[p-jackson]

I was playing around with this and noticed how, the underlined/purple text now appears everywhere. It's the default state to have your style inherited from somewhere.

What's good about the bullet icon for overridden styles

is that the default shows nothing special, and it's the override that changes up the UI. This inverts that. Now the default behaviour looks special and the override looks less special. You could just have a tooltip and no visual style change, but then it becomes very hard to discover.

What I'm imagining is that if the hit box for the tooltip was much bigger, like the entire panel was a hitbox, then any hover over the panel would show the detailed info.

This works with a mouse which isn't ideal. The panels which have a click which expands another side panel are better for showing extra info.

I'm sure you have plenty of UI proposals to choose from :)

[p-jackson]

The tooltip says things other than "Inherited from Global Styles" too, so I think just needs updated to "e.g. Inherited from ..."

[aaronrobertshaw]

Thanks, I missed going back over all this when I iterated on the PoC adding the style breadcrumbs to the tooltip.

[aaronrobertshaw]

Thanks so much for the thoughtful review and feedbacjk @p-jackson 🙇

I was playing around with this and noticed how, the underlined/purple text now appears everywhere. It's the default state to have your style inherited from somewhere.

For the controls highlighted, you're right there are values inherited, in this case the theme's theme.json file acting as the base for Global Styles. So the purple and underlined labels are "correct" in that regard.

Whether it is "too much", that is a question I might direct to @jameskoster and his expertise. For now it is inline with the original design issue and recent feedback.

What I'm imagining is that if the hit box for the tooltip was much bigger, like the entire panel was a hitbox, then any hover over the panel would show the detailed info.

Initially, I looked at something like this too but wrapping more than the label meant that the tooltip there swallowed all tooltips on subcomponents which are as or more important to end users. So I deliberately kept the scope for this narrow.

[jameskoster]

Perhaps the underline could be more subtle (text-decoration-thickness, text-decoration-color)? With the underline applied we might also try without the purple accent—it's doing the same job as the underline but not as accessibly.

[aaronrobertshaw]

I've iterated further here and fix a few bugs too.

Here's a quick glimpse:

Screen.Recording.2026-05-08.at.10.57.24.pm.mp4

And here is how controls look without the purple color for reflecting inherited global styles (current PR state):

[github-actions]

Size Change: +11.4 kB (+0.15%)

Total Size: 7.73 MB

📦 View Changed

Filename	Size	Change
build/scripts/block-editor/index.min.js	426 kB	+4.52 kB (+1.07%)
build/scripts/block-library/index.min.js	353 kB	+2.18 kB (+0.62%)
build/scripts/edit-site/index.min.js	304 kB	+1.25 kB (+0.41%)
build/scripts/editor/index.min.js	498 kB	+1.11 kB (+0.22%)
build/styles/block-editor/style-rtl.css	20 kB	+653 B (+3.38%)
build/styles/block-editor/style-rtl.min.css	17 kB	+534 B (+3.24%)
build/styles/block-editor/style.css	20 kB	+643 B (+3.32%)
build/styles/block-editor/style.min.css	17 kB	+536 B (+3.25%)

_{compressed-size-action}

[aaronrobertshaw]

Quick update:

I'll be away for a little while but I'll address any feedback collected over the next two weeks as well as the failing tests when i'm back.

It is worth keeping in mind this is a proof of concept at this stage and the code and approach hasn't yet been polished to a production ready state. That said, please don't be shy in leaving feedback, especially on the design and UX side of things.

[jameskoster]

I think I'd lean toward omitting the purple colorisation (we can easily add it back later if the underline proves inadequate). Not a strong feeling though.

[aaronrobertshaw]

Thanks for the continued design direction here. I'll address the current feedback in the next couple of days once I wrangle the new wave of conflicts after other recent global styles projects landed.

[aaronrobertshaw]

It's been a while coming but I think I have this successfully rebased onto trunk. The state-based / responsive styling work that landed on trunk reshaped basically every panel and hook this PR touches, so just about all of the old code was in conflict.

As this PR stands now, the inherited global styles display has been relayed and updated on top of trunk and the state/responsive styles feature. A few notes:

• Inherited value lookup is now state-aware
• Didn't touch the per-state CSS rendering
• Found and fixed a regression on gradient clearing

Unit and e2es are green locally but treat this as an updated PoC. With as much conflict as the previous working version had, this needs proper manual testing to confirm the inherited value UX actually makes sense across every panel and every state.

I'll continue to give this some testing and polish before flagging for review in the near future.

[github-actions]

Flaky tests detected in 4e4ff76.
Some tests passed with failed attempts. The failures may not be related to this commit but are still reported for visibility. See the documentation for more information.

🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/29065169599
📝 Reported issues:

• [Flaky Test] Should navigate inner blocks with arrow keys #39607 in /test/e2e/specs/editor/various/writing-flow.spec.js