Establish a consistent pattern for navigation buttons that open sub-panels

[afercia]

Description

In the Site editor, some settings panels have sub-panels (drill-down menus in design jargon). The controls to open these sub-panels are usually NavigationButtonAsItem components (under the hod it's a Navigator.Button).

Some of these buttons do show a chevron icon to visually communicate they open a drill-down menu. Some don't.

It's not that clear to me what the criteria is to determine which buttons should show a chevron and which ones should not.

There may be reasons why some don't but I'd tend to think a chevron icon adds value as it makes the user experiences more predictable and communicates well what's going to happen when clicking one of these buttons.

There are other minor inconsistencies, for example some of these buttons have a border. Some don't.
I do realize the navigation buttons that are grouped in a set of logically related items need to be styled a bit differently. Still, the lack of a chevron icon introduces inconsistency and doesn't help predictability.

A few examples:

The following navigation buttons show a chevron icon:

• Styles > Colors > Edit palette
• Styles > Typography > Font size presets
• Styles > Browse styles
• Styles > Blocks
• Styles > Additional CSS

The following navigation buttons do not show a chevron icon:

• Styles root menu: Typography, Colors, Background, Shadows, Layout.
• Styles > Typography > Elements

The buttons undeer 'Elements' are particularly confusing to me. They look like the fonts ones above. However, the fonts ones open a modal dialog while the Elements ones open a drill-down menu. They basically look the same, but they do different things.

One more example:

• The custom shadows navigation buttons don't show a chevron icon. It's particularly confusing when there's only one custom shadow:

I'd like to propose to use a chevron icon for all the buttons that open a drill-down menu.
Also i'd suggest to consider some more consistency about borders and margins.

Step-by-step reproduction instructions

N/A
See the examples in the Site editor > Styles panel

Screenshots, screen recording, code snippet

No response

Environment info

No response

Please confirm that you have searched existing issues in the repo.

• Yes

Please confirm that you have tested with all plugins deactivated except Gutenberg.

• Yes

Please confirm which theme type you used for testing.

• Block
• Classic
• Hybrid (e.g. classic with theme.json)
• Not sure

[afercia]

Re: borders around the items: quoting @jameskoster from #66476 (comment)

I lean towards no strokes, because the 'contained' style feels better suited when items in the list are directly related to one another, e.g. managing shadow styles or font size presets.

I would agree that borders should either be used with some consistent meaning ot not be used at all.

What about:

• Use borders to separate items that are not logically grouped e.g. the items in the root of the menu: Typography, Colors, background...
• Do not use borders, and maybe use a border around the group, for items that are logically grouped.

[jameskoster]

I agree it would be beneficial to tidy this up. There's a lot to cover, so when we arrive at a satisfactory design we might start by documenting this on Storybook as a source of truth before implementation.

Use borders to separate items that are not logically grouped e.g. the items in the root of the menu: Typography, Colors, background...

The two 'types' of groups identified make sense, but in this case I would just use no borders. It seems to me the expectation is that menu items are unrelated unless otherwise indicated by the UI.

For instance adding a stroke to the container helps indicate the relationship of the children, and is a common existing pattern.

Other considerations:

• Should we use the smaller chevron icon (like in the navigation sidebar)? This might help indicate at the decorative nature of this element.
• Should the chevron only appear on hover/focus to avoid adding unnecessary noise to the UI?