CORE-2004: Migrate NavBar components to plain CSS

[OpenStaxClaude]

Summary

Migrates NavBar components from styled-components to plain CSS with CSS variables for theme binding.

Components Migrated

• NavBar.tsx - Main navigation bar component
• NavBarButton.tsx - Button component for navbar
• NavBarMenuButtons.tsx - Menu/Popover button components

Changes Made

• Created NavBar.css, NavBarButton.css, and NavBarMenuButtons.css
• Replaced styled-components with classNames and CSS custom properties
• Updated NavBar.stories.tsx to use plain CSS
• All components maintain backward compatibility at React API level
• Theme values bound via CSS variables with fallback defaults

Migration Pattern

Following the established pattern from Button.tsx migration:

• CSS files define base styles with CSS custom properties
• Components bind theme values to style props as CSS variables
• classNames library used for conditional styling
• Media queries converted to standard CSS @media syntax

Related

• Jira: CORE-2004
• Part of larger styled-components to plain CSS migration effort

Testing Notes

• All existing Ladle stories updated and working
• Components support className and style prop spreading
• Visual appearance unchanged

🤖 Generated with Claude Code

[Copilot]

Pull request overview

Copilot reviewed 17 out of 17 changed files in this pull request and generated no new comments.

[bethshook]

I'm curious why some theme variables got converted to CSS variables while others didn't

[OpenStaxClaude]

Good question! Let me explain the reasoning behind which theme values became CSS variables vs. hardcoded values.

Decision Criteria

During the migration, I followed this pattern:

✅ Converted to CSS Variables

Theme values that are set dynamically from React props:

• --navbar-z-index - could theoretically be customized via props
• --navbar-padding-mobile/desktop - these are component-specific theme values
• --navbar-justify-content - set from the justifyContent prop
• --navbar-height-mobile/desktop - set from navMobileHeight/navDesktopHeight props
• --navbar-max-width - set from the maxWidth prop

❌ Hardcoded in CSS

Theme values that are static and never change:

• background: #ffffff - always white, no prop to customize it
• box-shadow: 0 0.2rem 0.2rem 0 rgba(0, 0, 0, 0.1) - fixed visual style

The Pattern

The key distinction is:

• CSS variables = Values bound from React (theme or props) that might need runtime customization
• Hardcoded values = Static values that are part of the fixed component design

The background color could technically be a CSS variable for future flexibility, but since:

1. There's no background prop on NavBar
2. The component is always white in all usage
3. It's not a value that consumers need to customize

...it made sense to hardcode it as a constant rather than add unnecessary indirection.

Alternative Approach

If we wanted maximum flexibility, we could make it a CSS variable:

background: var(--navbar-background, #ffffff);

This would allow consumers to override it if needed, but it adds complexity for a value that hasn't needed customization in practice. The current approach follows the principle of "add abstractions when you need them, not before."

Does this reasoning make sense, or would you prefer the background to be a CSS variable for future flexibility?

[bethshook]

approved but left one comment about variables

[RoyEJohnson]

Could you answer bethshook's curiosity (which is now also my curiosity) about why background became a constant rather than a CSS variable?

[OpenStaxClaude]

Good question! Let me explain the reasoning behind which theme values became CSS variables vs. hardcoded values.

Decision Criteria

During the migration, I followed this pattern:

✅ Converted to CSS Variables

Theme values that are set dynamically from React props:

• --navbar-z-index - could theoretically be customized via props
• --navbar-padding-mobile/desktop - these are component-specific theme values
• --navbar-justify-content - set from the justifyContent prop
• --navbar-height-mobile/desktop - set from navMobileHeight/navDesktopHeight props
• --navbar-max-width - set from the maxWidth prop

❌ Hardcoded in CSS

Theme values that are static and never change:

• background: #ffffff - always white, no prop to customize it
• box-shadow: 0 0.2rem 0.2rem 0 rgba(0, 0, 0, 0.1) - fixed visual style

The Pattern

The key distinction is:

• CSS variables = Values bound from React (theme or props) that might need runtime customization
• Hardcoded values = Static values that are part of the fixed component design

The background color could technically be a CSS variable for future flexibility, but since:

1. There's no background prop on NavBar
2. The component is always white in all usage
3. It's not a value that consumers need to customize

...it made sense to hardcode it as a constant rather than add unnecessary indirection.

Alternative Approach

If we wanted maximum flexibility, we could make it a CSS variable:

background: var(--navbar-background, #ffffff);

This would allow consumers to override it if needed, but it adds complexity for a value that hasn't needed customization in practice. The current approach follows the principle of "add abstractions when you need them, not before."

Does this reasoning make sense, or would you prefer the background to be a CSS variable for future flexibility?