Navigation Block: develop a content-only representation

[mtias]

There should be a way to make edits to your menu while on content-only mode. The canvas edits should be restricted but the inspector menu should be reachable.

We should explore exposing the "menu list view" in the inspector of template parts or patterns that contain a menu when the user is on content-only mode.

There should be a clear way to reach that panel from the toolbar of the nav block and the template/pattern. Could be an "edit menu" that just toggles the inspector with the tab for the menu open.

[youknowriad]

How do you see this kind of feature being "declared" for block types. In other words, until now, block types were not aware about whether they are in "content only" mode or not. We only detected blocks that have a "content" role attribute and allowed some specific behavior there. How do you see that evolving, should block types receive some kind of isSection flag and enable/disable behavior.

[mtias]

I don't think we should abstract this too soon. The navigation block already has a special tab in the inspector, so perhaps it's part of formalizing that view down the road. Conceptually, I don't think blocks should be made aware of "modes".

[getdave]

Related

• https://github.com/WordPress/gutenberg/pull/65185
• https://github.com/WordPress/gutenberg/pull/65118

[SaxonF]

I think we can tie this work into the content only stream as well as synced patterns in a few iterative ways.

1. Add an "edit menu" button to the Navigation Block toolbar. This is not directly related to content only but it helps to resolve some of the same pain points. The navigation block would be special in that other blocks would go with a generalised label and less prominent action.
2. Treat template parts in the same way as synced patterns. Clicking a template part should always select the template part which contains an edit button. Clicking the edit button puts us into focus mode for the part (like synced patterns) with the inspector open. You can currently select the site ltitle block within a template part directly for example.
3. When editing a template part, and in an content only mode, show editable blocks in the inspector. An editable block may site logo, site title or navigation block.
4. Adjust the content only behaviour so that clicking a block that has deeper attributes (like navigation block) it drills down in the inspector but offers a pathway back up. This has previously been explored by @talldan as part of https://github.com/WordPress/gutenberg/issues/60021
5. Allow the selection of template part when in the new zoom out / content only mode.

It may look something like this

https://github.com/user-attachments/assets/e0456bda-d899-4710-bb94-0215b5943135

The above shows two ways of accessing a menu. The first via the content list, and the second via the canvas with an "edit menu" button that just opens inspector with menu tab open.

In future we can look at surfacing overridable properties directly vs drilling down like what is proposed above.

[draganescu]

until now, block types were not aware about whether they are in "content only" mode or not.

Conceptually, I don't think blocks should be made aware of "modes".

If blocks are not aware of the mode they're in than something like #60412 can't work. Either the block tells the block editor that something is editable in content only, or the block editor designates what is content in content only. We went the first route and the block tells the block editor via the role prop of attributes what's editable in content only.

But the navigation block does not really have any content. The content is stored in the navigation link and navigation submenu blocks which are navigation block children. Updating the defition of these two types (link and submenu) to include role content on attributes whcih are content partly gets us there.

https://github.com/user-attachments/assets/d3a8f82a-cd94-4cee-9cf1-fab758f1fd79

But, what is lost, we can't see the tree of links 😢 However that seems to be an issue for the whole block tree which is flattened in content only.

1. What's the problem with preserving the flat block tree for navigation as well?
2. What is wrong with editing on canvas? Why would we want the navigation list view? @richtabor expressed his concern about adding drilldown to content only, which is kinda the same with the proposal above (an edit button in navigation's block toolbar). I think we used to have one ...

About 2 there is something else to consider: if a user is only expected to replace pictures and text, then why do we expect them to rearrange the site's hierarchy?

[draganescu]

This could work in a world where we show controls for every attribute with role content in the inspector. That could work by allowing blocks to register these controls for the inspector when they are in content only for whatever reason. Then the navigation block could register this whole list view thing.

[draganescu]

A bit of trial and error:

• if the block is assumed to be able to mount an affordance in the inspector then it has to be selectable.
• in content only due to how the content locking works, there is no selectable block without a content role attribute
• making the ref attribute role content makes the block selectable and uneditable in canvas (good enough start)
• adding the "list" group inspector slot for when content only blocks are listed allows the off canvas list view of the navigation block to be shown in the inspector when it's edited in content only.
  • ideally when this block is selected the BlockQuickNavigation will not be shown
  • since the list view of the navigation block works like the normal list view it will not by default show any blocks
  • because all the blocks in navigation do not have any content role attributes
    • and if any are added (which makes sense say label for links) then they become editable in the canvas
    • and we don't want that
• to edit links and submenus from the offcanvas list view of the navigation block we need to add drill down to the inspector in content only, because that's the way navigation block works. Should we add it only for this block?

So we need some things to achieve this style of editing:

• a way for blocks to signal they're selectable without having any content role attribute (or we can go with rel)
• a slot marked for content only affordances
• a way to mark a tree as editable by the parent even if content only context exists, or have the blocks themselves set their mode
• drill down ...

[draganescu]

Follow-up from a discussion with @youknowriad we can update content only to:

• enable blocks with controlled inner blocks to expose these inner blocks in the block inspector via a list view
  • this list view auto engages when a block with controlled inner blocks is selected in content only mode
  • the block inspector will support drilldown for blocks that show this list view of inner blocks
• make blocks with controlled inner blocks in content only are selectable but not editable in the canvas

This is a good start for an exploratory phase which could answer things like:

• Where should this list view appear? Does it appear on its own, or do we squish it bethween parent styles and block quick navigation?
• How is this redefining content only? If all blocks with controlled inner blocks become editable via the inspector, we break the contract that only role="content" is editable in content only.
• How much can we bloat the list view with? To implement the ideas above we'll need a new flag in the list view that tells it to disregard content only and list the full block tree not the flattened editable one.
• How much can we bifurcate the implementation of the block inspector? To add drill down just for this list view but not for other blocks may be a very specific execution path with lots of code serving a single small UX surface.
• Is this UX actually good? Having some exploratory PR will allow hands on interaction.