Add accordion style menus to the navigation block

[talldan]

What problem does this address?

The navigation editor implements its own version of accordion style menus:
https://github.com/WordPress/gutenberg/blob/trunk/packages/edit-navigation/src/components/editor/style.scss#L15-L108

Because these styles aren't part of the block, they're very brittle and can break easily when the block's own css or classnames change.

What is your proposed solution?

Ideally they'd become part of the block itself, maybe as a block style?

[talldan]

I gave this a quick go, but quickly realised that challenge will be opening the accordion on the frontend with a click or focus. At the moment, all submenus open using hover.

[paaljoachim]

Perhaps we can tie in the Accordion block issue (The issue is long): #21584
As I believe the accordion needs to also become a component or in some way associated with a component. Then we have the component that can be used in various ways in various places.
@aristath @sarayourfriend

[draganescu]

I don't think the style of the navigation block's edit in the navigation editor is meant to be used elsewhere. In block editors (say post or template parts) there is a visual matching between the editable and the rendered states. In the block based navigation editor this does not exist.

How else could we solve the brittleness of these block based navigation editor styles?

[talldan]

I don't think the style of the navigation block's edit in the navigation editor is meant to be used elsewhere. In block editors (say post or template parts) there is a visual matching between the editable and the rendered states.

@draganescu Would you be able to go into more detail about this, why wouldn't you expect the block's editor interface to match the rendered state of the menu? The idea is to enable users that want to build accordion style menus on their site.

[draganescu]

Just to make it clear: I think this issue is great, my doubt it the UI of the block navigation editor seems tweaked not to be a WYSIWYG "accordion menu" builder but a good wat to manage nested trees that are not WYSIWYG.

why wouldn't you expect the block's editor interface to match the rendered state of the menu

I wouldn't expect the navigation block editor's interface to match the rendered state. I think that in it's default purpose the block navigation editor is a means to manage classic WP menus. From this perspective the UI is an efficient way to handle nested trees, not a visual representation of the menu in a live website.

In it's "block menu opt-in" state then we'd be dealing only with the block as it works in any other block editor, no special styles.

So, adding this to the block, as a block style, to create accordion menus is great! But we should add this if we want the block to support this kind of interactivity, not particularly to shield the block navigation editor. In other words (cc @jasmussen) what other kinds of menu interactivity do we want to support? Do accordions require some extra functionality rendered on the front like the responsive menu did?

[talldan]

The alternative would be to not load any of the core block styles in the nav editor, and instead style it completely from scratch. Could be worth exploring.

But I think there's enough overlap here to try this first. The UI in the navigation editor is already an accordion menu, and so an accordion style navigation block (whatever it may look like) would still serve a better and more stable foundation for the navigation editor than the current solution of completely overriding dropdown menus. I also personally don't think it will be an issue if the proposed accordion styles in the navigation block start to change over time, the editor and the block still have the same goal of providing a good editing experience.

Finally, the navigation editor in its basic backward compatible mode would probably never show theme styles, so I would expect the interface to be relatively simple and stable. A minimal base for additional enhancement—exactly what the editor needs.

[ciampo]

Crossposting from #21584 (comment) — Should we consider adding an Accordion component to the @wordpress/components package?

[adamziel]

This sounds like a style variation to me: Dropdown vs Accordion. What do you think? I'll explore that in a pr

[ciampo]

This sounds like a style variation to me: Dropdown vs Accordion. What do you think? I'll explore that in a pr

According to this answer from @mtias:

no, our UI components are React based intended for admin UI, an accordion block would be something implemented entirely differently and optimized for the front-end.

ee shouldn't look into adding such a component to the @wordpress/components package at the moment.

[adamziel]

@ciampo The way I understand it is that Matias makes a case for not adding an Accordion block to @wordpress/components. This issue, however, is about supporting accordion style menus in the navigation block. Tying it to an accordion block would be one way to approach it, but it would also involve a major refactor of the navigation block. What I'm proposing here is starting with adding a style variation to the navigation block.

[ciampo]

@ciampo The way I understand it is that Matias makes a case for not adding an Accordion block to @wordpress/components. This issue, however, is about supporting accordion style menus in the navigation block. Tying it to an accordion block would be one way to approach it, but it would also involve a major refactor of the navigation block. What I'm proposing here is starting with adding a style variation to the navigation block.

Thank you for the clarification — in that case then I don't think there are any issues with your exploration from my side.

[kathrynwp]

Closing this issue due to the Navigation Screen project being moved to an inactive status on the feature projects page in coordination with the project leads. (The developer documentation in the initial post are no longer accessible)

If this work is picked back up, issues can be revisited and reopened as needed. Thanks for pitching in on this early feature so the wider WordPress project could benefit from the lessons learned!