Navigation overlay menu: Fix submenu spacing. #35823
Merged
Conversation
This file contains 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
jasmussen
added
[Type] Bug
jasmussen
commented
Oct 21, 2021
| @@ -1,12 +1,3 @@ | |||
| // Normalize Link and edit containers, to look mostly the same. | |||
| .wp-block-navigation__submenu-container { | |||
There was a problem hiding this comment.
This doesn't appear to be the same. I think I recall menu item input fields looking gray form fields. This appears to be handled by the input component itself now.
jasmussen
commented
Oct 21, 2021
| @@ -67,12 +54,6 @@ | |||
| } | |||
| } | |||
|
|
|||
| .wp-block-navigation .block-editor-block-list__block[data-type="core/navigation-link"] { | |||
| & > .block-editor-block-list__insertion-point { | |||
There was a problem hiding this comment.
This insertion point is now popovered, so it isn't even in context of the navigation link anymore, so this should be dead CSS.
|
Andrew I asked for your review not urgently, but because it replaces a hardcoded gap value in the overlay menu with the new CSS variable. Just wanted to get that sanity checked, thank you! |
|
Size Change: -186 B (0%) Total Size: 1.07 MB
ℹ️ View Unchanged
|
7 tasks
|
Temporarily setting this as in progress, as I need to rebase it off of #35820 and push some small tweaks. |
jasmussen
force-pushed
the
fix/editor-submenu-spacing
branch
from
ca417c2 to
ba8fdc2
Compare
|
Alright, I've rebased this one, and simplified the rules a bit following feedback in #35820. Top and bottom margin was applied to all navigation link containers, causing extra spacing between block types in the overlay menu:
Now that spacing is only applied as a top padding on nested items, fixing it: Here's some test content you can use: Verify the contents of the overlay menu look good and nicely spaced out. The original issue with the editor remains fixed. |
andrewserong
approved these changes
Oct 22, 2021
There was a problem hiding this comment.
Thanks for the ping @jasmussen!
The changes to the gap values look good to me, and I tested that the spacing is now consistent in the editor and on the front end (and when changing via the block spacing UI):
| Before | After |
|---|---|
 |
 |
If we want to give users control over spacing within a sub-menu further down the track, it should be easy enough to opt into the blockGap feature, too, if we need to.
The CSS removals look good to me, I couldn't see any unexpected differences between trunk and this PR. The submenu container styling appeared to be correct, and the reasoning for removing the insertion point display:none sounds reasonable too, given it's in a popover. Since I haven't spent much time looking at how the Navigation block works, feel free to get another review too, if this is an area where you need a confidence check!
Unrelated to this PR, I noticed that if (with overlay switched off) the submenus are set to Open on click, then the position of the icon is the same in the editor and on the front end. However, if it's set to hover, then on the front end the right arrow sits too close to the edge of the div (it looks like the arrow gets rendered outside of the a element that sets the padding?):
| Editor | Front end |
|---|---|
 |
 |
Also, I did notice that while selecting blocks in the overlay state, the block's toolbar controls are not visible (presumably hidden by the overlay's background?). Is that a known issue? (Obviously not related to this PR as it's happening on trunk, too). I'm testing in TT1-Blocks.
Those two things are outside the scope of changes in this PR, though, so just thought I'd share them since I noticed them, but otherwise this PR LGTM!
Sounds good. We definitely want some customizability, just have to figure out how far we can go on this one, but good to know!
Great catch, I think I can fix that up. I'll set a reminder and look at it separately!
Yes, this is intentional for now insofar as you can't actually edit items inside the overlay state very well. It's definitely something to be revisited, but it all relates to how much or how little control we want to/can add here. Thanks for the review! I'm feeling pretty good about this one, so I'm going to land it when the checks pass, but I'm always easy to find for followups if there are any! |
jasmussen
force-pushed
the
fix/editor-submenu-spacing
branch
from
f211549 to
32d8833
Compare
vcanales
pushed a commit
that referenced
this pull request
Oct 27, 2021
* Fix submenu spacing. * Fix flex spacing.
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.
Description
In the overlay menu, nested menu items were bunched together in the editor:
But on the frontend things looked right:
This PR fixes that, now they both look the same:
How has this been tested?
Insert a menu with nested submenu items. Test the appearance in the overlay menu, editor and front should look the same.
Also test the navigation screen, as this PR removes some CSS that appeared to be dead. It looks right to me.
Checklist:
*.native.jsfiles for terms that need renaming or removal).