Try: Fix navigation gap & padding issues. #35752
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -231,7 +231,7 @@ | |
| .wp-block-navigation, | ||
| .wp-block-navigation .wp-block-page-list, | ||
| .wp-block-navigation__container { | ||
| gap: var(--wp--style--block-gap, 2em); | ||
| } | ||
|
|
||
| // Menu items with background. | ||
|
|
@@ -242,7 +242,7 @@ | |
| &, | ||
| .wp-block-navigation .wp-block-page-list, | ||
| .wp-block-navigation__container { | ||
| gap: var(--wp--style--block-gap, 0.5em); | ||
|
There was a problem hiding this comment. I'm not sure why the fallback didn't work for me, but you can test on trunk: use empty theme, which doesn't supply a block gap value, then add a background color to the navigation block and observe how items collapse. Removing the calc and simplifying the selector seems to fix it for me. There was a problem hiding this comment. This is strange. I'm not sure why either, but when I don't use the shorthand definition, it looks as expected. row-gap: calc(var(--wp--style--block-gap, 0) / 4);
column-gap: var(--wp--style--block-gap, 0.5em);
With shorthand
Having said that, I think having consistent gap/column values makes sense and I don't see any strange UI issues with the extra bit of row gap. 👍 There was a problem hiding this comment.
Just an idle thought (and I'm sure there's a good reason not to do this), but I was wondering if since this block opts in to the line height support, whether we need to use There was a problem hiding this comment. Might be worth an experiment, thanks for the suggestion @andrewserong. The Navigation Block does already opt-in to line-height. I think the difference would be that the submenu text would also feel the effects of any line-height changes. Fooling around with vertical spacing via line-height: With gap spacing only:
And I think line-height is rather meant to define a font/text property? I'm no expert though and may be interpreting the specs incorrectly. There was a problem hiding this comment.
I like to think that line height and gap can coexist, but also that for spacing things out, gap will be more intuitive. I also still have hopes that we can have the user surfaced block spacing control toggle between unified/axial, at which point you can tweak if you need to. |
||
| } | ||
| } | ||
|
|
||
|
|
@@ -256,7 +256,7 @@ | |
|
|
||
| // When the menu has a background, items have paddings, reduce margins to compensate. | ||
| // Treat margins and paddings differently when the block has a background. | ||
| .wp-block-navigation:where(.has-background) .wp-block-navigation-item__content { | ||
|
There was a problem hiding this comment. Possibly a recent regression as of https://github.com/WordPress/gutenberg/pull/35716/files#diff-d66a4ed73d0d50a799547b78db235a4bad3428a0decb8895752032cd849d01f0R254, or the followup in https://github.com/WordPress/gutenberg/pull/35725/files#diff-d66a4ed73d0d50a799547b78db235a4bad3428a0decb8895752032cd849d01f0R46, but using the generic class (which we should've been using anyway) fixes an issue where has-background menu items had zero padding, when they should in fact have had some. |
||
| padding: 0.5em 1em; | ||
| } | ||
|
|
||
|
|
@@ -465,7 +465,7 @@ | |
| } | ||
|
|
||
| // A default padding is added to submenu items. It's not appropriate inside the modal. | ||
| a { | ||
|
There was a problem hiding this comment. Small fix for the overlay menu, to space things right. |
||
| padding: 0; | ||
| } | ||
|
|
||
|
|
||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm aware this changes both the horizontal and vertical gap into a single gap property. But there didn't seem to be value in making this one be different.