Repository navigation
fix(nav): Fix dark and mismatched navigation menu colors - #130236
Conversation
📊 Type Coverage Diff✅ no issues found |
Sentry Snapshot Testing
|
The HSL version darkened bright avatar colors far past the default gradient, so a yellow logo started the menu header near black. Scale the color in linear RGB until its OKLab lightness matches each default stop instead, which keeps the hue and stops exactly at the default's lightness. Gray logos say nothing about the brand, so they keep the default gradient. Refs DE-1832
The user menu header took its gradient from the user's photo, so it rarely matched the organization menu next to it. Use the organization's avatar for both, and fall back to the default gradient when there is no organization. Refs DE-1832
2949155 to
78cba97
Compare
|
bugbot run |
There was a problem hiding this comment.
✅ Bugbot reviewed your changes and found no new issues!
Comment @cursor review or bugbot run to trigger another review on this PR
Reviewed by Cursor Bugbot for commit 78cba97. Configure here.
78cba97 to
14671b9
Compare
14671b9 to
f0adfb5
Compare
Add a frameColor prop to AvatarButton that sets the color of the frame around the avatar, the border and raised edge. The button stays unaware of where the color comes from. A new useOrganizationPalette hook takes the current organization's colors in one place: the menu header gradient, and the frame color the organization's own avatar button uses. NavigationMenuHeader and a new NavigationAvatarButton read it themselves, so both menus and both buttons in the primary navigation always share the organization's colors. The button frame only applies with settings v3, where the menu headers are shown. Refs DE-1832
f0adfb5 to
f056f14
Compare
Core components may import color, but the later spec override restored the restriction for their tests, forcing eslint-disable comments. Lift it for core specs only.
…olor Scaling linear RGB kept light avatar colors' whitish tint, so the header gradient came out muted. Cap the lightness in OKLCH instead, keeping the hue and as much chroma as sRGB allows.
Jesse-Box
left a comment
There was a problem hiding this comment.
@priscilawebdev Maybe this should be a separate PR entirely, but while I think the gradients clearly look better, but Im a bit un-easy about determining the button chonk based on the avatar.
I feel like just keeping the default colours are present on our secondary buttons ensures a degree of contrast for both themes.
The organization colors only apply to the navigation menu headers, not to the avatar buttons. This reverts commit f056f14. Refs DE-1832
The button's border and raised edge took a color sampled from the avatar. Only the navigation menu headers should take the avatar's color, so the button now keeps the default button colors. Logos that don't fill the frame are still inset. Refs DE-1832
…vatar" This reverts commit f38d429.
The button's border and raised edge took a color sampled from the avatar. The Settings v3 design uses the neutral button edge, and only the navigation menu headers take the avatar's color. Logos that don't fill the frame are still inset. Refs DE-1832
Logos with transparent corners or edges were inset with padding on the white button face, so round logos looked small and boxed in. The Settings v3 design has every image fill the button edge to edge. Refs DE-1832
This reverts commit d5628f8.
The default button edge is too light to stand out around an avatar. Frame every avatar in border.neutral.vibrant instead, the gray the suggested state already uses, whatever the avatar's color. Padded logos keep their inset. Refs DE-1832
This reverts commit a76307f.
The avatar covered the button's own border and drew a transparent one in its place, so the avatar button had no outline, unlike other buttons. Draw the container border in the button's neutral edge color. Refs DE-1832
This PR only fixes the menu header gradient. Refs DE-1832
I am addressing the button's changes now in the PR #130893. Good call! |
Changed
via @priscilawebdev.
--
View Session [Sentry]