Navigation Component: Style

[Copons]

The Navigation component should:

• Be on par with the most recent design drafts.
• Be flexible enough to be used in the most disparate ways.

Discussion points:

• Should Navigation be height: 100%? Should it be a consumer concern? Should we expose a fullHeight optional prop? cc @psealock
• Should we offload the styling burden to the consumer? Should we create a light and dark theme and expose them through a theme prop? cc @ItsJonQ

---

FYI currently the navigation looks like this:

And it can be tested in npm run storybook:dev.

[ItsJonQ]

@Copons Thanks for following up and summarizing some of these points!

Should Navigation be height: 100%?

This is an interesting question! For my attempt, I was quite hands-off as far as style goes, but I did give it full height.
I feel like Navigation should have styles that allow for some of it's features to work correctly.

To be more specific, height (and potentially overflow) styles may be required for it's slide animation transitions to work.

Should we offload the styling burden to the consumer?

I believe that would be best. I feel like the Navigation component should be primarily responsible for managing and rendering a nested panes/screens, which can be affected either by (internal) "links" or external state.

What the Navigation container looks like, what an individual pane/screen looks like, and what a screen may contain should be entirely up to the consumer - which gives us a lot of flexibility and control.

[Copons]

@Copons Thanks for following up and summarizing some of these points!

Should Navigation be height: 100%?

This is an interesting question! For my attempt, I was quite hands-off as far as style goes, but I did give it full height.
I feel like Navigation should have styles that allow for some of it's features to work correctly.

To be more specific, height (and potentially overflow) styles may be required for it's slide animation transitions to work.

I'm pretty certain the height doesn't affect the animation, as it would be applied to the main wrapper (which wraps the animation component).
The overflow on the other hand is probably required, yes.

Anyway, I guess that full height is kind of implied by a Navigation, and it would be easily overridable by specific cases.

Should we offload the styling burden to the consumer?

I believe that would be best. I feel like the Navigation component should be primarily responsible for managing and rendering a nested panes/screens, which can be affected either by (internal) "links" or external state.

What the Navigation container looks like, what an individual pane/screen looks like, and what a screen may contain should be entirely up to the consumer - which gives us a lot of flexibility and control.

I'm not sure I agree entirely. 🤔
I'm all for offering flexibility and control, but I'd also strive to keep a certain degree of consistency and reusability.

Right now we have two well defined use cases for this component:

• Left-hand dark sidebar similar to the wp-admin sidebar.
• Right-hand light sidebar similar to the block/document sidebar.

We could sort the colors out by providing two very lightweight themes (easily overridable, e.g. by the user's admin theme colors, or by the component consumers own styles), and then we could find a good middle ground between the two use cases.

For example, in your "light" example the menu title has a bottom border, that's missing in the "dark" drafts.
We could either let consumers style the border on their own, risking having navigations with inconsistent styles, or discuss if adding/removing the border to both themes.

[Copons]

Note in case we forget: currently the text colors are "inverted" compared to the design drafts.

Element	Draft	Current
Menu title	white	white
Search button	white	grey (white on hover)
Group title	grey	white
Item	white	grey (white on hover)

[jameskoster]

Purely in terms of style I think what we have currently is OK. If the technicals are buttoned-up feel free to close this @Copons.