@draganescu for "Support drag and drop to reorder blocks in list view" shouldn't we be pointing to #25067 instead? (or maybe a separate issue to enable drag and drop for the block list view, as it's already working on the Navigation screen.) #19703 isn't about list view but the actual block interface.

Thanks for catching that @tellthemachines 👍 I've corrected the link.

Circling back to this issue, since it has been mentioned in the Editor chat summary 27th January.

The list above contains no indications on how menus will be shared between templates. An example would be a main navigation, which would be present on every template.

Right now you can use a template part for this. Will this be the way going forward?

Right now you can use a template part for this. Will this be the way going forward?

I think that's so far the most logical conclusion. It might make sense to add "navigation" as one of the validated terms for #27337 and automatically create such parts upon menu creation if we can reduce unnecessary UX overhead. One thing that is not entirely clear yet is how independent navigation should be from the header and whether that should always be the case regardless of how the menu is built. For example, in some themes header and navigation would be virtually indistinguishable and creating further template parts would seem a hindrance. Some themes with complex mega-menus, the navigation would also be the header. However, in cases where the menu is a simple list of the root pages its reusability as is becomes a lot more desirable.

Add support for separators between menu items #23292

Anyone know the correct issue number for this? #23292 is an apparently unrelated PR.

Good catch, I corrected the link to the separator issue, it was #23293.

Recent additions like the Page List block, and the incoming menu item setup state (#28440), take giant steps toward a better user experience. At some point, we'll want to create patterns that leverage the navigation block, so we can visualize the variety of different navigation menu designs possible. Currently the divergence in markup between front and backend makes that tricky, and the following efforts would help that a lot:

• The closer the admin markup is to the frontend, the less CSS we will need to write to style both, and the fewer edgecases we will need to handle. It sounds like #24644 can potentially solve that.
• #28575 would further simplify this effort, helping ensure that custom menu items are closer in markup to those inside a Page List.

Both these efforts will benefit the navigation block structure and styling, including patterns. It might even make some of the other tasks easier to address also.

Added #29036 to the list.

Added these three Page List css class related ones:

#29422
#29423
#29437

Added List View issues #29727 and #26141.

Is there any plan to increase the priority of #24644? It is in the high priority section, but right down at the bottom.

At the moment the Navigation block has lots of invalid markup when the following (non <li> elements) are inside the navigation block's <ul>:

• Placeholder Preview
• Page List
• Search Block
• Social Links

#24644 is supposed to resolve that by removing the nav block's ul.

I don’t think the order of the lists specify an order within the group, but if so I would also suggest #29036 and #24644 be a higher priority, as it's key to create a lean HTML markup with no ul wrapper and it impacts other work being done in the block.

To improve the legibility, I edited this one a little bit:

• Added strikethrough on fixed tickets
• Lowered priority on “Expand / collapse submenus: #18395." — This one is very difficult on the frontend, and is arguably not urgent.
• Removed duplicate "Make it Mobile Responsive"

A couple of the items could use clarification:

• "Explore use of semantic template parts for automatic reusability."
  What does this mean? Is there a ticket it can point to?
• "Flyout submenus"
  This one could also do with some context. Is there a ticket it could link to? Is it fixed by #29869? Is it a duplicate of "Expand/collapse submenus"?

"Explore use of semantic template parts for automatic reusability."

I believe #27337 and mtias' comment above provide the context for that. It is not actionable yet, though, so there is no specific ticket, but I'll link the issue as a context in the top comment 👍

Regarding flyout submenus in the Navigation block, there is #29101. Is that what "Flyout submenus" in the list refers to?

I lowered the priority of "Allow insert before / after: #23603". It's a task that needs addressing, but it does not seem as high priority as all the others.

I added #28575 to the list as high priority, because we need to level the playing field between menu items generated by the Page List block, and regular menu items:

I checked off "Flyout menus", as #29932 has landed, if that item referred to additional things, please feel free to uncheck.

Added "Add an API to retrieve content-only inner blocks" #30674 to the list

Checked off #29437 thanks to @gwwar's work!

Added:

• Provide a better way to disable/enable nav block features for the nav editor #30007
• Sidebar/Inspector control improvements #30370
• Add separate overlay color option #29963
• Make it clearer how to delete a Link Block without a link #30116
• Improve flow for deleting submenu items #30115

I've created a Project Board as suggested by @gwwar to easier identify PRs needing review, and added all pending issues and most PRs to it.

Feel free to add/tweak columns as needed! 🙂

Awesome, thanks @priethor !

Checking off "Add Home block (#20542)" courtesy of @gwwar 🎉

Thanks to work from @vcanales, I checked off "Explore responsive (hamburger) menu: #22824"

Checked off "Allow folding of nested items" thanks to @gwwar 🥇

There's been a conversation about enabling more diverse navigation block patterns, that provide highly opinionated defaults, for example site navigations that show exactly 3 menu items, a site logo, and instagram/facebook/twitter links. Perhaps even with the navigation items pre-labelled.

To enable such patterns, the setup/placeholder state for the navigation block needs to be reconsidered with a focus on menu item setup states instead. Consider these:

Those are intrinsically opinionated patterns, and should be allowed to lean into that, just like we already do for Button patterns:

The buttons above have their labels pre-filled, but they link no-where. You could think of that as an "opinionated Buttons block pattern", and we need to be able to accommodate similarly opinionated ones for the navigation block. Only, it also needs to be much clearer that those buttons really do link no-where, and that you need to point them to their destinations, or they won't be very useful.

This is particularly important for the navigation block, and we have a neat little trio of tickets that, when addressed together, should get us pretty far on that:

• Navigation Block: Enhancement ideas for the empty placeholder (partially addressed by #32512)
• Blocks that link: Provide a split label/URL control and placeholder state
• Menu Item placeholder: Show page label in setup state

While those three tickets are not crucially urgent for the overall navigation block "phase 1" as outlined here, they are nevertheless important to address on our navigation block journey, and the solutions we find here can benefit not just Navigation, but also Buttons and potentially Social Links as well.

I'll add these three items to the navigation block board, as a start, but for anyone reading, let me know if we should add them to the body of this ticket as well.

On behalf of @tellthemachines I checked the box for "Multiple blocks available". 👏

On behalf of @georgeh I checked the "Add a separate color overlay option" 🏅