-
Notifications
You must be signed in to change notification settings - Fork 4.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Navigation Screen: Design Iteration #28675
Conversation
This looks great! The only thing that stood out to me to create more consistency between widgets and navigation screen is the overall top toolbar. Here's the current design for Widgets: Right now, the design above makes that top toolbar to add new, manage locations, etc feel like it's floating/disconnected from the experience: I don't know if more major design changes are expected for widgets but felt worth noting. Finally, for the "Editing: blog footer" section, this feels a bit awkward to me for some reason. I almost wonder if this could take a page out of the template navigation experience? This part specifically: Here's a pretend "mockup" if it can even be called that: |
I love the track this is on. Whether or not to top toolbar is a conversation worth having — I lean on the side of not replicating the block editor because these are screens built for different purposes, even if they are still technically block editors. However I also trust you and the others to consider all the challenges involved in choosing which direction to go. When I spin up this PR I see this:
There's a lot of space under each menu item. That's from an empty submenu that has a min height of 44px. So there's a little juggling to do there. Almost certainly a pre-existing and separate issue, but reloading the screen I got this: I like the idea generally of forcing the menu to be vertical. But it may end up being more work than is good. Just one example: The mover assumes a horizontal menu. There are probably going to be more issues as well. It could still be worth it, but it might be best to do the vertical menu as a separte PR exploration, so as to not hold up this one. Also most probably separate, the sidebar menu could use a little love. Delete is centered and the prase above with the checkbox wraps. |
I forgot to mention: if you like, I'm happy to set aside some time to collaborate with you on this PR with you. Just let me know! |
To expand on forcing vertical navigation, the addition of the permanently expanded list view was probably created to address that very same issue: making it easier to configure a menu that has more than a couple of nested levels. Because we don't have a solid alternative, and to keep the good things from this PR, perhaps it's best to keep that list view for now and explore how to better integrate that separately. |
A few things in my mind:
|
It's not the best UI for just a handful of links (most navigations?). It might be good to switch or default to list view open if we detect more than one or two levels of nesting. |
@draganescu These things are actually the same as they are in I'm starting to wonder if we should ditch the nav block and just treat this as a normal block list with the same blocks that the nav block supports. The nav block's settings could be the equivalent of document settings. Not really sure the nav block is offering much apart from 'Show submenu indicators'. |
Separately I made some PRs that could be merged into this.
|
A similar thought occurred to me while working on this PR; Adding a Menu block that is container meant specifically for the context of this dedicated screen. I'm not sure what the pros/cons are if we diverge from the Navigation block, so I mostly avoided the thought. |
Ultimately I'll defer to you all on timing, complexity, experience. My instinct is that there's value in some wysiwyg even on this screen. |
I think this one is is a good place to merge. There is plenty more work to do, but this is an experimental, beta screen. I feel pretty comfortable with merging this as-is, and continuing to iterate. |
…erything. Also, a nasty hack to fix the block focus outlines.
…elow their parent link.
…der to parents whose children are being edited.
… hides the ability to toggle submenu indicators.
76df2d4
to
1f20e66
Compare
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.
There are a few issues remaining, but given how big this PR is I'm going to approve and merge, as it'll be easier to tackle them in smaller parallel PRs.
Things that seem like they'll be good follow-ups:
- Work on responsive designs/styles for the new screen
- Reimplement Clear block selection in the navigation editor when clicking editor canvas #28382, which regressed in this PR.
- Improve the way this works with the Page List block, which was merged just before this PR. Page List still shows flyout style menus.
- Accessibility testing
- Find a solution to the amount of extra navigation block styling this introduces (mentioned in comment below)
Thanks for all your work @shaunandrews, the new design is an exciting step!
.wp-block-navigation { | ||
margin: 0; | ||
font-size: 15px; | ||
padding: $grid-unit-15; | ||
} | ||
|
||
.components-spinner { | ||
.wp-block-navigation-link { | ||
display: block; | ||
margin: 10px auto; | ||
|
||
// The following attempts to fix the focus outlines | ||
&.is-selected > .wp-block-navigation-link__content, | ||
&.is-selected:hover > .wp-block-navigation-link__content { | ||
box-shadow: 0 0 0 var(--wp-admin-border-width-focus) var(--wp-admin-theme-color); | ||
} | ||
|
||
&.block-editor-block-list__block:not([contenteditable]):focus::after { | ||
display: none; | ||
} | ||
} | ||
} | ||
|
||
.edit-navigation-editor__list-view { | ||
border-top: 1px solid $gray-300; | ||
padding: $grid-unit-20; | ||
.wp-block-navigation-link__content { | ||
padding: 0; | ||
margin-bottom: 6px;//$grid-unit-05; | ||
border-radius: $radius-block-ui; | ||
|
||
@include break-medium() { | ||
border-left: 1px solid $gray-300; | ||
border-top: none; | ||
margin-top: 0; | ||
width: 300px; | ||
&:hover { | ||
box-shadow: 0 0 0 $border-width $gray-300; | ||
} | ||
} | ||
|
||
.edit-navigation-editor__list-view-title { | ||
font-size: 1.2em; | ||
margin: 0; | ||
.wp-block-navigation-link__label { | ||
padding: $grid-unit-15; | ||
padding-left: $grid-unit-30; | ||
|
||
// Without this Links with submenus display a pointer. | ||
cursor: text; | ||
} | ||
|
||
.components-spinner { | ||
display: block; | ||
margin: 100px auto; | ||
// Position the submenu icon so it appears to the left of | ||
// the Link. All the extra specificity is help override the | ||
// rotation on the SVG. | ||
.wp-block-navigation .wp-block-navigation-link .wp-block-navigation-link__submenu-icon { | ||
position: absolute; | ||
top: 6px; | ||
left: 2px; | ||
padding: 6px; | ||
pointer-events: none; | ||
|
||
svg { | ||
padding: 0; | ||
transform: rotate(90deg); | ||
} | ||
} | ||
|
||
// Submenus | ||
// There's a bunch of stuff to override just to get submenus to | ||
// as a normal block element. | ||
.wp-block-navigation-link.has-child { | ||
cursor: default; | ||
border-radius: $radius-block-ui; | ||
} | ||
|
||
// When editing a link with children, highlight the parent | ||
// and adjust the spacing and submenu icon. | ||
.wp-block-navigation-link.has-child.is-editing { | ||
> .wp-block-navigation__container { | ||
opacity: 1; | ||
visibility: visible; | ||
position: relative; | ||
background: transparent; | ||
top: auto; | ||
left: auto; | ||
padding-left: $grid-unit-15; | ||
min-width: auto; | ||
width: 100%; | ||
border: none; | ||
display: block; | ||
|
||
&::before { | ||
display: none; | ||
} | ||
} | ||
} |
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.
The maintainability of all the block styles being defined here will be difficult. If the block's own styles change there's the strong potential for bugs in the navigation editor. That or unused styles. The goal seems to be to make the submenu items appear inline (not as a flyout menu):
As a follow-up it'll be worth thinking about how we can solve this. For example, perhaps this is a style variation of the nav block?
We'll also have to make this work for the Page List block which was just merged to master.
Would be interested in your thoughts @tellthemachines.
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.
Actually, I remember now about the discussion around using a dropdown block for submenus (#23745), so maybe in some distant future the nav screen would use a collapse/expand block (I completely forget the proper name for this?) instead of dropdown.
The current design of the beta Navigation screen looks like this:
There's a few problems here:
This PR aims to resolve those problems, and give the beta Navigation screen solid footing for future improvements. Here's the updated design as seen in this PR:
fixedToolbar
mode.