Navigation: Use gap instead of margin. #32367
Conversation
jasmussen
added
[Type] Code Quality
|
Size Change: -156 B (0%) Total Size: 1.04 MB
ℹ️ View Unchanged
|
There was a problem hiding this comment.
This tests well with just link menus. A minor concern would be the Can I Use stats it is available in most desktop and current mobile, but the previous Safari still show 11% usage.
Also, the margins are off for social links, you can see in the GIF they are up against the border while the links are not. This looks the same without this change, so not a regression, so if an issue can be addressed elsewhere.
My biggest question for approving the change is lack of support in the older mobile Safari browser.
|
Thanks for looking. Valid point about social links — and ultimately I think we should move those towards using gap as well: it's a much simpler way of ensuring harmonious spacing without an escalating set of width and nth-child rules for margins around wrapping elements. In this particular case, the before/after should visually look identical, with and without gap for social links:
The other part of your question is a good one: can we start to use gap more widely considering many are still using Safari 13? Utimately yes, I think so, because what happens if gap is not supported is a purely decorative issue, and not functional. So if not now, then at least soon. We landed this change for Buttons, making the same evaluation of complexity vs. legacy support. Navigation is perhaps a bit more prominent, with lack of support being potentially more noticable. The other half of the equation is global styles support, as tracked in #32366. Right now you can actually change margins using global styles, but since you can't change the gap, arguably it would remove that feature (even if currently not used at all). Perhaps I should mark this one as blocked until #32366 is addressed, and then we can revaluate the browser support situation. |
jasmussen
added
the
[Status] Blocked
jasmussen
force-pushed
the
try/navigation-gap
branch
from
1643568
to
6dad80f
Compare
|
Since #32659 has landed, this is now unblocked and can be picked up again, so I rebased it. One thing I noticed though, is that there's a bit of a markup discrepancy when combining the nav menu with social links. Here's the editor:
Note how there's
Note how the social links is a descendant of Here's the frontend:
Here, the gap doesn't affect the Social Links block at all, and the answer lies in the markup:
Here, Social Links is a descendant directly of While this is something I can work with, I'm not sure this discrepancy is intentional, and if we could fix it it would be nice. @tellthemachines @draganescu do you know if this is intentional or something I could/should ticket? |
jasmussen
removed
the
[Status] Blocked
jasmussen
force-pushed
the
try/navigation-gap
branch
from
6dad80f
to
c33a4cd
Compare
It is intentional, a result of the decision to decouple the front end from the editor markup in the Navigation block. The divergence is exactly because we need to wrap the Nav link items in a For the styling to work across the two sets of markup, can we ignore the If it's any help, we could remove the |
Ah, gotcha. I just meant that social links could still have been inside the
Yes, I think that's an option. Let me dive into the markup once more with this helpful context, and see what might work best 👍 👍 |
|
Dove in for a bit, and formed two thoughts. First off, it does seem like the
In quick debugging it seems like it would work and be valid:
It's entirely possible I'm missing a markup nuance though, and I can work with the existing markup if need be, let me know! |
That div is only there on the editor side because we need an element that's not the outer
Sure, we can do that. My only reservation is that, though it's semantically correct, it might not make sense in terms of the content. The only other nested And due to the way we wrap menu items in Having said that, if it does make it a lot easier to style the nav consistently, we should still consider doing it. |
|
All excellent points! I think I'll pause this one until the new unified CSS classes have landed. The followup refactor will likely make it much more clear what the best path forward is. Thanks for your input 👌 |
jasmussen
added
the
[Status] Blocked
jasmussen
force-pushed
the
try/navigation-gap
branch
from
c33a4cd
to
126b63d
Compare
|
Rebased this one and fixed an issue also outlined in #34351. |
tellthemachines
force-pushed
the
try/navigation-gap
branch
from
00ec8c5
to
6ddc5ca
Compare
There was a problem hiding this comment.
Rebased this PR so we can test with the recently-merged #33316. It's working well! The only part that isn't working is the Pages List styles; I left comments on that below.
Also, I now see why you were apprehensive about the Social Icons markup:
The only way I could find of getting all these items to line up was setting everything to display: inline, but that won't allow justification, so not a viable solution.
I like the idea of allowing individual social icons in the Nav, instead of being grouped in a Social Icons block. Can you think of any reasons not to try that? If not, I'm happy to give it a go in another PR 😄
| &:last-child { | ||
| margin-right: 0; | ||
| } | ||
| .wp-block-navigation__container .wp-block-page-list, |
There was a problem hiding this comment.
On the front end, wp-block-page-list isn't inside wp-block-navigation__container, so this won't apply. I think we could go with .wp-block-navigation .wp-block-page-list instead.
There was a problem hiding this comment.
Excellent, that worked:
| &:last-child { | ||
| margin: 0; | ||
| } | ||
| .wp-block-navigation__container .wp-block-page-list, |
|
Thank you for the rebase and the review. Let me address your comments and see what I can do about the page list. |
jasmussen
removed
the
[Status] Blocked
|
Forgot to answer this one:
The only downside is that the block inserter becomes very unwieldy having items like Page Link intermixed with every social link under the sun. #34041 should mitigate that, especially if paired with some way to curate the quick inserter. I would definitely agree that it's a better experience to not have to have an extra wrapper just for social links. |
|
I guess this one is mostly ready! I had some comments in #33812 (comment) on how to better integrate with global styles, and perhaps make the navigation block a flex container as defined in block.json rather than in CSS as is done here. But that's probably best left as a followup. |
There was a problem hiding this comment.
Page list is looking much better now 🎉
There's a slight discrepancy in spacing between regular items and page list items due to the padding applied to wp-block-navigation-link__content, especially noticeable in the vertical nav:
But that's unrelated to these changes so let's fix it separately.
The only downside is that the block inserter becomes very unwieldy having items like Page Link intermixed with every social link under the sun.
Good point 😄 I guess it comes down to whether it's a better experience to have all those links directly available, or to have to add an intermediate block in order to access them.
If we do want to keep using the Social Links block, another thing we could try is nesting the whole block inside the wp-block-navigation__container and then adding role="presentation" to the extra wrapping li and ul so that semantically the social links are siblings of the main list items. I haven't actually tried this yet, so we'd need to test it well to make sure it works. In terms of the layout though, having that extra wrapper in place means that individual social links won't be able to wrap like the other nav items - much like what currently happens with Page List.
Actually forget it, those are theme styles, aren't they 🤦 |
If you were using TT1 to test, there are some known issues with menu item paddings and margins there. I did some testing but couldn't reproduce, but if we find a way to reproduce I'll be happy to follow up and fix!
Honestly I think your point is well made, and that the issue is worth solving. Some of the efforts outlined in #34041 will need to handle these cases anyway, and a curated quick inserter I honestly believe would benefit all blocks with nesting. Thank you for the reviews. I think I'll land this one and follow up if anything comes up. |
Description
This PR refactors the navigation block to use
gapinstead of margins for spacing items out. The rules remain the same, if a navigation block has a background color, it has a smaller gap, than if it doesn't.Submenu items should be unaffected, as those are not spaced out using margins at all, purely the padding of items themselves.
This comes with a few benefits:
gap#32366, this could provide a neat interface directly in the navigation block for controlling item-spacing.Testing instructions
Compare this branch with trunk, and the spacing should be the same. Before:
After:
Please test with and without backgrounds, vertical and horizontal, frontend and backend. Test a few themes. Some themes like TwentyTwentyOne provide style overrides for the navigation block that are obsolete, so won't necessarily be accurate, see also https://core.trac.wordpress.org/ticket/53220.
Screenshots
Checklist:
*.native.jsfiles for terms that need renaming or removal).