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?

[afercia]

For instance adding a stroke to the container helps indicate the relationship of the children

I'd agree a border around items visually suggests they're logically grouped items.
A order between items should be used to visually communicate they're logically separated.

[jameskoster]

I don't think we need to explicitly indicate both cases. If a border on the container denotes the relationship of the children, then the absence of a border inherently indicates the opposite, with clearer visual distinction.

Let's see what @WordPress/gutenberg-design thinks though.

[jasmussen]

Chevron to indicate drilldown makes sense, and related items in an itemgroup (bordered) could similarly have chevrons. In the case of fonts, though, these open a modal, so they should probably not have the chevron.

[jameskoster]

@jasmussen we're discussing patterns that indicate when drilldown items are directly related (e.g. font size presets) versus those that are not (e.g. top level menu items). Examples in #66448 (comment).

Also:

• 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?

[auareyou]

It seems the immediate accessible solution here would be to add chevrons (or another clear affordance) that make the drill-down behavior obvious to everyone. However, if adding chevrons to all buttons introduces too much visual noise—which I agree it does—it might be worth reconsidering the overall visual language around settings.

For instance, if we take the Typography roles list as an example, perhaps changes could happen in place with a different type of control, such as a select menu, an accordion, or another component that doesn’t pull users away from the main view of the typography panel.

Looking at industry standards in other design and development tools, the inspector panel typically keeps sections corresponding to the user’s selection always visible. Advanced settings or drill-downs often occur within popovers, reducing the number of "round trips" while still allowing for focused interactions.

Example from Figma:

Example from Webflow: