Global Styles: Show a local-override diamond indicator for inherited values and ship them to Core by annezazu · Pull Request #80649 · WordPress/gutenberg

annezazu · 2026-07-23T18:25:50Z

Important note

This is meant to keep the conversation going, design and solution wise. The code is completely AI generated though and I welcome devs to close out this PR or take it over to see this through.

What?

Follow-up to #77894 / #80506. Iterates on how block-inspector controls signal that a value locally overrides one inherited from Global Styles.

Nothing at rest. A control that inherits simply shows the inherited value (as it already does). There is no marker, badge, or underline.
A diamond indicator on override. Setting a local value shows a small filled diamond next to the control with an "Overrides inherited styles" infotip.
Relies on current reset options. The diamond is a status indicator only and it performs no action itself. Clearing a local override uses the panel's existing reset controls.
Now enabled in Core. Previously, the whole treatment was gated on IS_GUTENBERG_PLUGIN. That gate is removed, so inherited values and the override indicator ship in WordPress Core builds too.

Here's a video:

infotip.display.inherited.styles.mp4

Why?

Per design/accessibility feedback in #80506:

Inheritance is already implied by what the control shows, so marking only the exception (a local override) is less UI and less to start with.
The diamond's whole purpose is to reveal its explanation, so it is an infotip. This is being done based on @mirka feedback since the diamond's whole purpose is to reveal its explanation. It uses @wordpress/ui Popover with an openOnHover trigger, which keeps the content reachable by hover, keyboard focus, tap.

How?

Replaces the interactive InheritanceResetButton with InheritanceOverrideIndicator — a Popover.Trigger (openOnHover) hosting a filled-diamond SVG, with the "Overrides inherited styles" text in the popover.
Used by the standard InheritanceToolsPanelItem controls and the custom controls (color, gradient, shadow, duotone, background image).
Removes the at-rest dotted-underline label treatment.

Testing Instructions

Add a Paragraph and open the block inspector.
Controls whose value comes from Global Styles show that value with no marker.
Change one (e.g. Line height, or a text color). A diamond appears next to it.
Hover/focus the diamond → "Overrides inherited styles" infotip. It performs no action on click.
Reset via the Typography/Color panel's ⋮ options menu.

🤖 Generated with Claude Code

annezazu · 2026-07-23T18:44:21Z

The only annoyance I have found thus far in this approach comes down to how the tools panel reset option works. When I set a typography option like Font or Appearance, I go looking to reset it and there's no obvious "Reset" button. Meanwhile, if you set Color, it shows me a clear "RESET" label right there. This seems to be by design where some options have a reset option via the checkmark in the ⋮ menu. It's not clear though that clicking the checkmark is what clears it. These two different reset patterns in the same menu is an annoyance but not a blocker to landing something at this point. Here's a video explaining:

annoyance.mov

annezazu · 2026-07-23T18:45:42Z

@jasmussen can you give a final 👍🏼 design/UX wise?
@mirka can you give this a review design systems wise?
@t-hamano @ramonjd can one/both of you help see this through code wise, whether it's taking over this PR or creating a new one?
@joedolson can you check this out accessibility wise, especially since I saw your recent comment here?

Thank you all. I know this has been a lot over what might seem like a small detail but it will permeate so many aspects of the editor if/when it lands.

mirka · 2026-07-23T19:04:19Z

+ */
+export function InheritanceOverrideIndicator( { className } ) {
+	return (
+		<Tooltip.Root>


We're starting to differentiate between tooltips (which are just for showing the accessible name of icon buttons), and infotips (which are a dedicated mechanism to show arbitrary content).

So here we'll want to use the Popover component from @wordpress/ui instead of Tooltip (the basic implementation pattern is documented here).

Got it! Just updated the PR to use that. Will update the description and video too for good measure in a moment.

aaronrobertshaw · 2026-07-23T19:06:22Z

These two different reset patterns in the same menu is an annoyance but not a blocker to landing something at this point.

The ToolsPanel was initially a means of providing progressive display for controls as the inspector and global styles grew more crowded. Part of this was the dichotomy of "shown by default" and "optional" items.

The "shown by default" controls are more "show all the time". So in the menu they are always checked, because they can't be toggled off, they display the RESET label when they contain a local value. Optional items are tricky, with dual behaviour that has always been a bit awkward, they need to be able to be toggled on and off for display, but at the same time allow reset functionality. So if a control is being turned off, the idea historically has been that this also clears or resets the control.

Earlier iterations of the ToolsPanel had two separate menu groups allowing these different groups of items to have a more aligned UI. Ultimately though, the design decision was the better option was a single menu, without groups.

I hope that provides a little context

joedolson · 2026-07-23T20:20:02Z

There's a UI problem when there's also a contrast warning:

For me, the distinction between this and a blue dot is very subtle. It's so small, that the difference between a diamond with slightly rounded corners and a circle are practically non-existent. I think that this needs some refinement to make it more visually distinct from those dots, as used elsewhere.

Functionally, this works, but the popover reads twice: this is something that should be improved in the popover info handler. It has both an h2 and contained text, but they contain the same text. This means that when you open the popover, it announced both the heading and the text.

The heading should only be present if there is additional text that is different from the heading and different from the aria-label. Otherwise it's just a lot of duplication.

In my opinion, this should still use the popover tooltip model, because there is no additional content. The purpose of a tooltip is to convey an accessible name when it isn't visible; the purpose of a toggle-triggered tooltip is to provide access to more extended information, e.g., a help dialog. Since the entirety of the information that needs to be conveyed here is contained in the accessible name, using the infotip just creates a lot of excess verbosity with no added value.

ramonjd · 2026-07-23T21:36:01Z

can one/both of you help see this through code wise, whether it's taking over this PR or creating a new one?

I won't get time this week sorry.

ramonjd · 2026-07-23T22:10:40Z

For me, the distinction between this and a blue dot is very subtle.

Agree. Commented over here #80506 (comment), but I think maybe it's enough to show the inherited value for now. Before the confusion arose that a block background was red for example, but the control didn't reflect the value. At least now the control matches the value in the block attributes. 😄

Anyway, thanks for iterating here and trying out things! If I get time next week I can take a look, but I might have to wait until @aaronrobertshaw is back for support.

mirka · 2026-07-23T22:15:03Z

In my opinion, this should still use the popover tooltip model, because there is no additional content. The purpose of a tooltip is to convey an accessible name when it isn't visible; the purpose of a toggle-triggered tooltip is to provide access to more extended information, e.g., a help dialog. Since the entirety of the information that needs to be conveyed here is contained in the accessible name

@joedolson For context, we were aligning with upstream guidance to separate labeling popups and informational popups. And the infotip pattern will indeed be necessary when the popup wants to contain anything more than plain text. It just happens that this instance still doesn't.

The strings in this branch are currently a bit off (very redundant), but the intended implementation is such that the trigger's aria-label is something like "More information about X", where it tells you that the button is going to expose additional information about X. In this particular case, the aria-label could be something like "Where is the X value coming from?" or "See X inheritance" or whatever, and then the popover can show more information about this. As we continue enhancing this inheritance indicator feature, the infotip popover can contain richer layouts, and maybe even links or buttons to edit the parent control its inheriting from.

Let me know if this general infotip pattern needs to be changed in some way, since we need to cover this kind of pattern in the design system in some way or another.

…values Iterates on how block-inspector controls signal that a value locally overrides one inherited from Global Styles (follow-up to WordPress#77894 / WordPress#80506). - Nothing at rest: an inheriting control shows the inherited value with no marker (removes the at-rest dotted-underline label treatment). - On a local override, a small filled diamond appears next to the control with an "Overrides inherited styles" tooltip. - The diamond is a status indicator only and performs no action; clearing a local override relies on the panel's existing reset options. Replaces the interactive InheritanceResetButton with a shared InheritanceOverrideIndicator (a Button hosting a filled-diamond SVG wrapped in a @wordpress/ui Tooltip), used by the standard InheritanceToolsPanelItem controls and the custom color, gradient, shadow, duotone, and background image controls. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

Addresses review feedback: the diamond's purpose is to reveal the "Overrides inherited styles" explanation, which is an infotip, not a tooltip (a tooltip is only for the accessible name of an icon button). Uses @wordpress/ui Popover with an openOnHover trigger so the content is reachable by hover, keyboard focus, and tap — a tooltip is unavailable to touch and screen-reader users. Also fills in the PR number in the CHANGELOG entry. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

Reverts the infotip in favour of the @wordpress/ui Tooltip, per the accessibility review on WordPress#80649: the entire message is already the trigger's accessible name, so the infotip's Popover.Title and Popover.Description only duplicated it and screen readers announced the same string three times. A tooltip popup is visual-only, which keeps the aria-label as the single source of truth. The trigger goes back to an enabled Button whose only job is to host the tooltip, so tapping it still performs no action. Also inlines the Diamond SVG into the indicator and trims the JSDoc, which had grown to restate the review discussion. Co-Authored-By: Claude <noreply@anthropic.com>

`InheritanceOverrideIndicator` hand-rolled a Tooltip.Root/Trigger/Popup wrapper around a Button, which is what Button already does for itself: with a `label` and no children it renders its own tooltip and mirrors the string into `aria-label`. Collapsing to a single `<Button label icon />` drops the wrapper, the duplicated label constant and the `@wordpress/ui` import. Passing the diamond through the `icon` prop instead of as children lets `Icon` size the SVG and adds the `has-icon` class, so most of the CSS that existed to undo the default Button chrome (sizing, padding, background, box-shadow, cursor, text-transform) is no longer needed. `size="small"` replaces the `__next40pxDefaultSize={ false }` opt-out and its lint exemption. Co-Authored-By: Claude <noreply@anthropic.com>

The WordPress#77894 entry had been rewritten in place to describe the final diamond indicator, which erased the fact that the at-rest treatment shipped as a dotted underline plus inline reset and only later changed. Restore that entry to its original wording and add a separate WordPress#80649 entry for removing the dotted underline and reset affordance in favour of the local-override diamond. Co-Authored-By: Claude <noreply@anthropic.com>

Drop the redundant `carries no reset action or menu` case (the indicator's lack of a reset is already covered where it matters) and the explanatory comments that merely restated what the assertions already show. Also tighten the background-image `hasLocalOverride` comment. Co-Authored-By: Claude <noreply@anthropic.com>

Both tests asserted that no "Reset to inherited value" button renders, but the override indicator no longer has any reset control — that label exists nowhere in the source, so the assertions were always trivially true. Remove them and simplify the indicator test to just check the diamond renders. Co-Authored-By: Claude <noreply@anthropic.com>

Condense the JSDoc and SCSS comments in the inheritance module — they had grown to restate design rationale and CSS mechanics at length — to the point each one needs. Also drop the "Reset to inherited value" absence checks from the border-panel shadow tests; that label no longer exists in the source, so the assertions were always trivially true. The real "remove" button assertions, which cover actual behavior, stay. Co-Authored-By: Claude <noreply@anthropic.com>

t-hamano · 2026-07-24T07:04:06Z

I have made the following changes to this PR.

Use tooltips instead of infotips. As far as I've read the discussion here, I feel that tooltips are sufficient for now. Visually, tooltips are also less prominent than infotips.
Remove redundant unit tests and simplify overly long comments.

For me, the distinction between this and a blue dot is very subtle. It's so small, that the difference between a diamond with slightly rounded corners and a circle are practically non-existent. I think that this needs some refinement to make it more visually distinct from those dots, as used elsewhere.

I noticed that the SVG was being squashed, causing it to render smaller than expected. It should now be more visually apparent than before.

I believe this is ready for another review, but I found one issue.

Some panels have a reset button that appears on mouse hover or focus.

reset-button.mp4

When a global style is inherited, this reset button is replaced by an indicator.

If the indicator has a reset action, this is fine, but that is not the case in this PR. This means that for color-based UIs with inherited styles, this reset button will become unavailable.

The two approaches that come to my mind for a solution are these.

Add a reset action to the indicator. However, this deviates from the original purpose of this PR.
Restore the reset button to the left of the indicator button. This would look something like this:

reset-button.mp4

However, if the contrast checker is activated, the UI can feel more cramped.

I welcome any ideas to resolve this contradiction!

tyxla · 2026-07-24T08:01:05Z

I believe it's quite important that we surface this information to the user, and this looks like a great solution 👍 Thanks to everyone for working hard to find the best path forward here!

mirka · 2026-07-24T08:22:14Z

Use tooltips instead of infotips. As far as I've read the discussion here, I feel that tooltips are sufficient for now.

Let's not forget that tooltips are not available on touch devices though.

jasmussen · 2026-07-24T08:33:46Z

Thanks for the continued work, and thanks to all participants in the discussion. This is on a good track.

can you give a final 👍🏼 design/UX wise?

On a high level: nothing at rest, something on override feels like a very strong starting point. I like the diamond shape to symbolise connection as well. I do believe that through sustained iteration over multiple releases, including listening to feedback from users on the first versions of this, we might possibly find even cleaner and clearer locations for this button. But a single button that shows the tooltip/infotip on tap, with nothing at rest, feels like a clean path forward, with room to grow.

Some details. Joe mentions the diamond size, and I agree, it's a bit small right now. It's a "know it when we see it" deliberation, but for now it's on the smaller size. As a quick test, does this resonate?

I think Aki may have already fixed this issue in a mid-stream patch that unsquashes it, so it may be a non-issue in the latest.

There's still some vertical misalignment, and the tap target can ideally be a bit larger. But that's not blocking for this, I recognise it doesn't translate perfectly to the ItemGroup piece so I'll defer to developers on this. But just sharing for clarity:

However, if the contrast checker is activated, the UI can feel more cramped.

This is valid, and one of the reasons I think it's good to land this minimal first version for now, and keep exploring iterations to this. In that sense, I think we should restore that reset button, even if it becomes cramped; it was there before, removing it now is a step backwards.

If we were focusing on 7.2 iterations, I would like to try and find a cleaner system for precisely where this dot appears, so that it can ideally be completely consistent across every design tool. ItemGroup is one of the main outliers here, and one possible solution would be to move the diamond inside the flyout, in context of the control that sits there. But again, I would not do that for this first iteration. What do you think?

t-hamano · 2026-07-24T08:41:46Z

Thanks for the feedback!

Use tooltips instead of infotips. As far as I've read the discussion here, I feel that tooltips are sufficient for now.

Let's not forget that tooltips are not available on touch devices though.

That's right. It probably depends on what we want to prioritize, whether we should use a tooltip or an infotip.

I think Aki may have already fixed this issue in a mid-stream patch that unsquashes it, so it may be a non-issue in the latest.

Regarding the size, it should have been fixed.

There's still some vertical misalignment, and the tap target can ideally be a bit larger.
In that sense, I think we should restore that reset button, even if it becomes cramped

Let's try to deal with these two.

The reset button, override indicator and contrast warning each claimed the same absolutely-positioned slot at the toggle's inline end, so they could only be shown one at a time and the label's reserved space was hardcoded per combination. Group them in a single positioned row instead, and derive the label's max-width from how many buttons that row actually holds, so all three can coexist and the label always keeps clear of them. Also make the label a FlexBlock so a long name shrinks itself rather than squashing the color indicator next to it. Co-Authored-By: Claude <noreply@anthropic.com>

The reset button and the override indicator shared one absolutely-positioned slot at the toggle's inline end, so they could only be shown one at a time, and the toggle reserved a fixed inline-end padding whether or not anything was rendered there. Group them in a single positioned row instead, and derive the toggle's padding from how many buttons that row actually holds, so both can coexist and the label reserves no space when there is no action at all. This mirrors the layout the color panel now uses. Co-Authored-By: Claude <noreply@anthropic.com>

The remove button and the override indicator shared one absolutely-positioned slot at the toggle's inline end, so they could only be shown one at a time. Group them in a single positioned row instead, and derive the toggle's inline-end padding from how many buttons that row actually holds, so both can coexist and no space is reserved when there is no action at all. The toggle label also had no truncation, so a long translation ran under the actions row. Render it as a FlexBlock and clip it with an ellipsis, which keeps the shadow icon from being squashed as well. This mirrors the layout the color and background image panels now use. Co-Authored-By: Claude <noreply@anthropic.com>

ramonjd

I had a look with a view to helping out code-wise, but I think I was a bit premature. Happy to help see this through once the tooltip/infotip call is made.

ramonjd · 2026-07-27T03:41:10Z

-	right: 0;
-	top: $grid-unit;
-	margin: auto $grid-unit auto;


I think ColorGradientSettingsDropdown's reset button loses its positioning in some cases.

Here's the Cover block color control:

Nice catch, fixed.

ramonjd · 2026-07-27T03:45:42Z

+				// The button exists only to host the tooltip, so a click does
+				// nothing.


Sorry, if I'm way too early and you're still working on this. 😄

So this is intentional? I can focus on the button, and it has hover states but in most of the controls (color aside) it has no affect when triggered.

The pointer cursor/hover styles seem contradictory to me. Is there a way to remove interactivity here, or does it rely on the tooltip/infotip decision?

To indicate to screen readers that inherited styles are being overridden, I believe at least this element needs to be keyboard focusable. However, it doesn't necessarily need to be actually clickable by mouse. I've opted to use a span with an img role instead of a Button component. This should avoid redundant cursor and hover styles.

inherited-indicator.mp4

Each toggle repeated a per-count comment explaining which buttons the reserved space was for. The button combinations differ per control and drift as buttons are added, so state the shared rule once instead: the actions are absolutely positioned, so the toggle reserves room on the right for as many of them as are rendered. Co-Authored-By: Claude <noreply@anthropic.com>

The reset button was the toggle's only trailing control, but the label's reserved right-hand space is now keyed off an `__actions` element and its child count, as in the background, shadow and duotone panels. Wrap the button in a `Stack` carrying that class so the sizing rule applies and further actions can join the same row. Co-Authored-By: Claude <noreply@anthropic.com>

The indicator exists only to host its tooltip, so rendering it as a Button meant suppressing the click it advertised. Render a `role="img"` span with `tabIndex` through `Tooltip.Trigger` instead: the tooltip stays reachable by keyboard, but the element carries no interactive semantics. Styles that came from Button (size, focus ring) move to the span. Co-Authored-By: Claude <noreply@anthropic.com>

t-hamano · 2026-07-27T08:34:43Z

This PR is ready for code review. Let's discuss again whether we can ship this as 7.1 Beta 4.

annezazu · 2026-07-27T13:07:33Z

At this point, I would like to land this for the next beta, assuming the code is on track. I think adding the reset option back in per this also greatly helps with the reset being so far away in some cases. Right now, this feels like it strikes the right balance of usefulness while leaving open progressive enhancements for 7.2 where more design thinking can be done.

I heard an additional idea: don't show any indication of even a local override. This is perhaps even bolder than showing only the override. I don't think that changes anything in this PR, but mention it as something even more conservative to fall back on depending on feedback given here.

Yes! This is a great fallback to have for this release if we need to scale back further to still land something of value, without pulling out the entire feature.

Thank you to @t-hamano for driving this forward, code wise, and for everyone else for chiming in to refine it further, experience wise.

fcoveram · 2026-07-27T15:05:37Z

Thanks a lot for working on this. Great exploration.

Due to the use of dot indicator for unseen messages and unsaved changes, my first reaction was that each control will remove the indicator after saving them. It’s not fully clear to me where the value comes from in the default state, and perhaps we could continue exploring that idea based on the latest comments shared in #80506.

Showing where the value comes from by default is also in line with how the UI communicates the sync nature of template parts, sync patterns, and block bindings. I see potential in pushing that direction.

I heard an additional idea: don't show any indication of even a local override. This is perhaps even bolder than showing only the override. I don't think that changes anything in this PR, but mention it as something even more conservative to fall back on depending on feedback given here.

+1 to this idea. Showing the inherited value is a great improvement and feels safe to go with this version.

aaronrobertshaw · 2026-07-27T15:14:07Z

I'm a little out of the loop on these efforts now but @fcoveram there is additional work around displaying where these styles come from in:

Block editor: Display tooltip for inherited global styles with breadcrumb path #79992
Block Inspector: Display inherited Global Styles breadcrumbs via label tooltip #80150

That work is only waiting for something that can carry that information as discussed in these recent PRs.

I'd also like to state that simply filling a control with a value, that we cannot 100% guarantee matches what is rendered on the canvas, without saying where it comes from seems like a poor experience to me.

Imagine a user selecting a block and noticing the background color control has a color value in it. I decide I want to clear it. I've learnt previously that anything in these controls can be clear by resetting the control. I now do that but nothing happens as resetting the control now will reset to the inherited value state.

Yes, that is closer to what is rendered in the canvas and the reality of things but as a user I'm confused as to where this comes from, why I can't get rid of it without having to define another color. Additionally, not all controls or styles can easily be "cleared" or unset.

So not showing there's a local override, to me, means there's further confusion around why resetting a control or style value magically appears as a different value that I still don't know where it comes from.

mikemcalister · 2026-07-27T15:22:35Z

Thanks for everyone's thoughtful work on this. I've been playing with a few of the prototypes this morning.

One thing that sticks out to me, which has been brought up by a few folks now, is that this does add some visual clutter to an already jam packed sidebar. The number of styles available and the potential for diamonds next to many of them (often with different vertical alignment) can make the sidebar harder to parse and navigate quickly.

Here's one last minute idea to consider. In this concept, instead of showing a diamond indicator on each element, we simply highlight the kebab menu where the user can both see what settings have overrides and can reset them as well.

Another benefit here is discoverability of the kebab menu. We do a ton of WP training through Ollie and you would be surprised how many people don't know this menu item exists or have never interacted with it. Drawing a little attention here with a subtle highlight color could help with discoverability and awareness of overrides.

joedolson · 2026-07-27T15:47:53Z

With a highlighted kebab menu, we are back in the position of having some trouble exposing the information visually. We shouldn't change the accessible name of the control, as it still does the same thing, so we can't use the existing tooltip. We could add text inside the kebab menu that gives the context - that way it can be more detailed, but is at a click remove to discover.

It may also run into some challenges from a design front making sure it works with all the existing button states, but it's possible, if we're willing to accept that you'd have to expand the kebab menu to understand the reason for the highlight.

mikemcalister · 2026-07-27T16:15:56Z

@joedolson That's fair, I haven't seen the full scope of the previous convos so this was just a quick thought. I would defer to those resolved conversations.

Happy to dive in deeper, but my designer and long-time-block-editor-user spidey senses tell me these diamonds scattered across settings aren't quite there yet. We could make the case that they're iterative, toward a more comprehensive solution, but in that case, I don't know if it's worth the temporary step.

If there was user research done on this problem, it might be helpful to see how they describe the issue or know how these overrides are currently confusing to them.

Personally, I've never had a user mention this issue to me, though they have plenty to say about many other block editor quirks! That doesn't mean it hasn't confused them, except that I think it becomes pretty clear once they interact with it.

annezazu · 2026-07-27T19:21:20Z

Assuming this PR lands, I also want to put forth this draft PR to bring back breadcrumbs to the tooltip. It's one thing to say the styles are inherited (and still useful!). It's another thing to provide direction around where it's inherited from so you can better understand if you want to keep the override in place. Once more, this is AI generated but intentionally pulls from prior art from @aaronrobertshaw PRs. It feels safe to add back into this release, considering this approach. Let's discuss there.

richtabor · 2026-07-28T01:42:46Z

I understand the intent here—to indicate when a value has been changed from the default—but I don’t think the current treatment is particularly helpful.

Do we know this is a problem people face?

Quick notes:

The diamond/dot doesn’t clearly communicate what it means or what action the user can take, and the tooltip doesn’t make that much clearer.
It’s also confusing that switching back to the default option doesn’t actually reset the value; the user has to know to use the separate "reset" behavior (basically hide/re-enable if they want to see the field again).
The indicator itself does nothing. Maybe if it were some sort of reset action it could hold its weight.

More broadly, this system of controls has evolved into something fairly complicated, and this feels like it adds another layer of UI without making the behavior easier to understand.

One thing that sticks out to me, which has been brought up by a few folks now, is that this does add some visual clutter to an already jam packed sidebar.

+1

highlight the kebab menu where the user can both see what settings have overrides and can reset them as well.

At least with this you can interact with the object that's different.

if we're willing to accept that you'd have to expand the kebab menu to understand the reason for the highlight.

@joedolson what do you mean here?

t-hamano · 2026-07-28T06:17:18Z

Thank you all for your feedback. To clarify the current situation, while this type of UI is not yet shipping in 7.1 Beta, a more interactive UI is already available in the Gutenberg plugin 23.7. We are working on this PR here as an intermediate approach for 7.1.

In the Gutenberg plugin, it works as follows: control labels with inherited values are underlined. If their style is locally overridden, a blue dot appears, which you can click to reset the local override.

Taking this current situation into account, we can discuss what the ideal UI is in the end, and whether we should provide some kind of intermediate UI in 7.1.

joedolson · 2026-07-28T17:44:11Z

@richtabor re:

if we're willing to accept that you'd have to expand the kebab menu to understand the reason for the highlight.

If we use a highlight on the kebab menu, then we can't have a tooltip that indicates anything new. The kebab menu represents the feature group's options label, e.g. "Typography options", and that needs to stay constant - the tooltip is a representation of the accessible name of the control. The accessible name needs to inform users what the control does, so the tooltip can't change.

So the information about what that highlight meant would have to be accessed somewhere else; my expectation would be as information inside the options menu that the kebab expands.

aaronrobertshaw · 2026-07-28T18:20:27Z

So the information about what that highlight meant would have to be accessed somewhere else; my expectation would be as information inside the options menu that the kebab expands.

I feel like hiding this information away within the ToolsPanel menu will detach it even further from the affordance and control it relates to. Additionally, the items within the menu are already sort of overloaded managing both display of controls and resetting them.

annezazu · 2026-07-28T19:37:14Z

This is being punted from 7.1.

Hey folks. Thanks again to everyone for the hard work here to iterate on this, debate details, and try it out. Per this slack thread, this is being punted from the release. At the root of the reason why are a few things: lack of a solid design approach, lack of robust exposure and feedback from users due to it not landing soon enough, and lack of agreement on a way forward. What we did not lack is a willingness to try and experiment.

Going forward, I think we can land an experiment in Gutenberg to be extra safe that includes a version of this PR/potentially this PR, along with breadcrumbs. As the work in Properly support Global Styles inheritance indicators UI evolves, that can then be added in to solidify the design approach.

ramonjd · 2026-07-28T23:58:11Z

Going forward, I think we can land an experiment in Gutenberg to be extra safe that includes a version of this PR/potentially this PR

What do folks think here, could we replace is the IS_GUTENBERG UI checks with an experiment guard for now?

andrewserong · 2026-07-29T00:17:16Z

What do folks think here, could we replace is the IS_GUTENBERG UI checks with an experiment guard for now?

I think that's the way to go, it'll give more flexibility for experimenting and playing around with the UI.

ramonjd · 2026-07-29T00:25:21Z

I think that's the way to go, it'll give more flexibility for experimenting and playing around with the UI.

Thanks for confirming! Getting a quick PR up now.

ramonjd · 2026-07-29T01:53:28Z

Experimental toggle PR:

Global Styles: Put the inheritance UI behind a Gutenberg experiment #80815

github-actions Bot added the [Package] Block editor /packages/block-editor label Jul 23, 2026

annezazu mentioned this pull request Jul 23, 2026

Global Styles: Replace the inherited-value underline with an indicator button #80506

Closed

mirka reviewed Jul 23, 2026

View reviewed changes

annezazu and others added 4 commits July 24, 2026 12:15

t-hamano force-pushed the update/inheritance-override-indicator branch from a6fee9d to 4ddea4a Compare July 24, 2026 04:44

t-hamano and others added 4 commits July 24, 2026 13:51

t-hamano and others added 3 commits July 24, 2026 19:38

ramonjd reviewed Jul 27, 2026

View reviewed changes

t-hamano and others added 4 commits July 27, 2026 15:50

Merge branch 'trunk' into update/inheritance-override-indicator

c3312fd

t-hamano added this to WordPress 7.1 Editor Tasks Jul 27, 2026

github-project-automation Bot moved this to 🔎 Needs Review in WordPress 7.1 Editor Tasks Jul 27, 2026

This was referenced Jul 27, 2026

Global Styles: Show the inherited-from breadcrumb in the override indicator tooltip annezazu/gutenberg#1

Closed

Global Styles: Show the inherited-from breadcrumb in the override indicator tooltip #80757

Draft

annezazu removed the Backport to WP 7.1 Beta/RC Pull request that needs to be backported to the WordPress major release that's currently in beta label Jul 28, 2026

t-hamano moved this from 🔎 Needs Review to 🦵 Punted to 7.2 in WordPress 7.1 Editor Tasks Jul 29, 2026

ramonjd mentioned this pull request Jul 29, 2026

Global Styles: Put the inheritance UI behind a Gutenberg experiment #80815

Merged

JosVelasco mentioned this pull request Jul 30, 2026

Global Styles: explore a cascade popover for inherited-value overrides #80993

Draft

		// The button exists only to host the tooltip, so a click does
		// nothing.

Uh oh!

Conversation

annezazu commented Jul 23, 2026 • edited by t-hamano Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Important note

What?

Why?

How?

Testing Instructions

Uh oh!

annezazu commented Jul 23, 2026

Uh oh!

annezazu commented Jul 23, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

mirka Jul 23, 2026

Choose a reason for hiding this comment

Uh oh!

annezazu Jul 23, 2026

Choose a reason for hiding this comment

Uh oh!

aaronrobertshaw commented Jul 23, 2026

Uh oh!

joedolson commented Jul 23, 2026

Uh oh!

ramonjd commented Jul 23, 2026

Uh oh!

ramonjd commented Jul 23, 2026

Uh oh!

mirka commented Jul 23, 2026

Uh oh!

t-hamano commented Jul 24, 2026

Uh oh!

tyxla commented Jul 24, 2026

Uh oh!

mirka commented Jul 24, 2026

Uh oh!

jasmussen commented Jul 24, 2026

Uh oh!

t-hamano commented Jul 24, 2026

Uh oh!

ramonjd left a comment

Choose a reason for hiding this comment

Uh oh!

ramonjd Jul 27, 2026

Choose a reason for hiding this comment

Uh oh!

t-hamano Jul 27, 2026

Choose a reason for hiding this comment

Uh oh!

ramonjd Jul 27, 2026

Choose a reason for hiding this comment

Uh oh!

t-hamano Jul 27, 2026

Choose a reason for hiding this comment

Uh oh!

t-hamano commented Jul 27, 2026

Uh oh!

annezazu commented Jul 27, 2026

Uh oh!

fcoveram commented Jul 27, 2026

Uh oh!

aaronrobertshaw commented Jul 27, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

mikemcalister commented Jul 27, 2026

Uh oh!

joedolson commented Jul 27, 2026

Uh oh!

mikemcalister commented Jul 27, 2026

Uh oh!

annezazu commented Jul 27, 2026

Uh oh!

richtabor commented Jul 28, 2026

Uh oh!

t-hamano commented Jul 28, 2026

Uh oh!

joedolson commented Jul 28, 2026

Uh oh!

aaronrobertshaw commented Jul 28, 2026

annezazu commented Jul 23, 2026 •

edited by t-hamano

Loading

annezazu commented Jul 23, 2026 •

edited

Loading

aaronrobertshaw commented Jul 27, 2026 •

edited

Loading