Refine overlay edit button UI: move to link variant and add tooltip #73957
+65
−75
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
getdave
changed the title
getdave
added
[Block] Navigation
|
The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message. To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook. |
|
Size Change: -17 B (0%) Total Size: 2.58 MB
ℹ️ View Unchanged
|
Contributor
|
This is better for me. I wonder if we have similar patterns in other places that we can align on. |
Contributor
Author
Yes I was wondering about that. I looked in Storybook but didn't see anything in DataForms or anywhere that had a similar UI/UX. I wonder if @jasmussen has come across anything or has any better ideas? |
|
Flaky tests detected in 4c68f67. 🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/20162835667
|
Contributor
|
We do:
I've no strong opinion on what button style it should be, just that it should ideally be the same, one or other direction. I'm leaning towards tertiary, but if @jameskoster has the capacity to chime in, he'd know with certainty. |
mikachan
reviewed
Dec 12, 2025
Member
mikachan
left a comment
mikachan
left a comment
There was a problem hiding this comment.
This looks good and tests well for me.
However, I'm struggling to find any other similar buttons to this design, other than the example @jasmussen gave.
I'm not opposed to this design, but another option may be to use a hamburger/dropdown menu to contain the Edit link, similar to the one for the Menu tools:
I think I prefer the simple "Edit" link though, and I like that it's a clear action rather than being hidden behind another menu. Not strongly opinionated either way, and will defer to design on this!
| } | ||
|
|
||
| .wp-block-navigation__overlay-edit-button { | ||
| margin-top: $grid-unit-10; |
Member
There was a problem hiding this comment.
I don't think margin-top is needed if the button is absolutely positioned, or we should instead adjust the top positioning rather than using margin.
Contributor
Author
|
Ok this is nice inspiration. I'm glad I asked!
So we shoudl follow the
...possibly communicated with the help of icons. 
I'm very keen to avoid the pattern of hiding critical UI elements. As you say it needs to be clear, obvious and always present. |
Contributor
|
I think what I'm saying is that design wise, there's an existing pattern, but if the existing pattern is poorly implemented, we can improve it here, but also ideally follow up and improve the existing implementation. Is that fair? |
Contributor
Author
|
💯 This is an opportunity to
|
Contributor
|
It's just my 2c but I think it might make more sense to group the button with the input rather than the label. That would also create a more sensible keyboard flow. Though I acknowledge it's not quite as neat. 
Since the action is navigational ideally I suppose we'd use a link (still styled to look like a button if desired). If we're unable to use an actual link, then the |
Contributor
Author
Engineering issue (designers can ignore): Attempting to implement this I got to the above. The problem is that I'm having to artificially add the I tried the I think we should offer greater control over these form components by being able to pass custom |
Contributor
Author
|
@jasmussen noticed a "blink" of the admin when |
Contributor
|
Steps to reproduce the "blink":
Crucially, you have to reload the page between applying and clicking edit on the overlay button, so there's probably some caching going on. Note also that this was inserting a navigation block in the post editor (which is already a rarity), not the site editor, that may play a role too. |
Contributor
|
@getdave I'd rather accept that the help text doesn't span than hack the component If the UI component is not meant to offer this UI. |
Contributor
Author
|
I've discussed this away from Github with @mirka and the proposed design isn't compatible with our current forms components. To implement the proposed would require rebuilding It's not simple to modify the existing components with new extensions points so we may need to wait on the next iteration of form components to provide greater flexibility. @mirka may have more information on that. I propose (as per @youknowriad's comment) that we merge this PR with the compromise layout (help text not wrapping) and then circle back later (pre release) to implement the fully refined design. |
- Replace absolute positioning with HStack/FlexBlock/FlexItem layout - Change button variant from link to secondary - Add 24px top margin to align button with SelectControl input - Remove absolute positioning CSS rules - Use CSS variables for spacing
Change help text from 'Select an overlay to use for the navigation.' to 'Select an overlay for navigation.' to avoid text wrapping and improve UI appearance.
Update the test expectation to match the new shorter help text 'Select an overlay for navigation.' instead of the previous longer version.
Contributor
Author
|
I've updated this:
|
Brings in fix from commit f4d87b4 (PR #73919). When a selected overlay template part is deleted, the Edit button was still visible even though the template part no longer exists. This fix ensures the Edit button only appears when: - overlay attribute has a value - template parts have been resolved (hasResolved) - the selected template part exists in the resolved list This prevents the Edit button from appearing when the overlay selector correctly shows 'None (default)' after deletion.
MaggieCabrera
approved these changes
Dec 16, 2025
Contributor
MaggieCabrera
left a comment
MaggieCabrera
left a comment
There was a problem hiding this comment.
This is working as intended and the code makes sense to me. I'm approving tentatively but I'm unsure of the design. I googled how to translate Edit into German and the word is quite much longer, I'm not sure of this design pattern personally
jeryj
approved these changes
Dec 16, 2025
Contributor
jeryj
left a comment
jeryj
left a comment
There was a problem hiding this comment.
Approving with suggestions for cleanup. I don't see any blocking issues.
| help={ | ||
| overlayTemplateParts.length === 0 && hasResolved | ||
| ? __( 'No overlays found.' ) | ||
| : __( 'Select an overlay for navigation.' ) |
Contributor
There was a problem hiding this comment.
We should update this text in a follow-up. "Select an overlay for navigation." doesn't really explain to what the selection is going to do. It seems clear that I'm selecting an overlay, but I don't know what it's going to. I'd appreciate more context about that, like, "Customize the overlay appearance"
Comment on lines
118
to
123
| const isEditButtonDisabled = | ||
| ! overlay || | ||
| ! parsedTemplatePart || | ||
| ! hasResolved || | ||
| ! selectedTemplatePart || | ||
| ! onNavigateToEntityRecord || | ||
| isResolving; |
Contributor
There was a problem hiding this comment.
Do we need ! hasResolved and isResolving? Also, the Edit button only renders in this condition: { overlay && hasResolved && selectedTemplatePart && ( so maybe we can just put this directly in the button?
aria-disabled={ onNavigateToEntityRecord }
Contributor
Author
There was a problem hiding this comment.
Yeh some of this disable logic might be redundant now the design has changed.
Comment on lines
+175
to
+176
| aria-label={ editButtonLabel } | ||
| label={ editButtonLabel } |
Contributor
There was a problem hiding this comment.
label already sets the aria-label. You can remove the aria-label.
| .wp-block-navigation__overlay-edit-button { | ||
| margin-top: $grid-unit-10; | ||
| width: fit-content; | ||
| margin-top: $grid-unit-30; |
Contributor
There was a problem hiding this comment.
Could <Flex/> or <HStack/> handle this layout instead of adding CSS?
Contributor
Author
There was a problem hiding this comment.
No not with the HTML forced upon us by form components. This was a last resort.
Contributor
Author
|
Let's get these conflicts resolved and cleanup the final points that @jeryj suggested. We should bring this in. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
What
Refines the overlay template selector UI by moving the edit button to a more streamlined position and adding a tooltip for improved clarity.
Why
The previous implementation had the edit button as a large isolated button below the input, which created visual separation and took up unnecessary space. Moving it to a link variant positioned to the right of the control creates a more compact and intuitive UI. Additionally, the button's purpose wasn't immediately clear to all users since it only showed "[Edit]" as visible text, with additional context only available via aria-label for screen readers.
How
editButtonLabelmemoized value for both the tooltip and aria-labelScreenshot
Testing
trunk.