feat(ui): improve light mode theme consistency#384
Conversation
|
@kanikasharma-18 is attempting to deploy a commit to the adityapaul2603-gmailcom's projects Team on Vercel. A member of the Team first needs to authorize it. |
✅ Deploy Preview for astounding-nougat-da0f6a ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
📝 WalkthroughWalkthroughUpdates in ChangesClerk accent & light-theme adjustments
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~20 minutes Possibly related PRs
Suggested labels
Suggested reviewers
🚥 Pre-merge checks | ✅ 6 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (6 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
🧹 Nitpick comments (3)
src/input.css (3)
353-358: 💤 Low valueVerify that overriding Tailwind's internal gradient variables is safe.
This code directly overrides Tailwind's internal CSS custom properties (
--tw-gradient-from,--tw-gradient-to,--tw-gradient-stops) to customize thefrom-whitegradient in light mode. While this works, it's fragile because these are Tailwind's internal implementation details that could change in future versions.If Tailwind refactors how gradients work internally, this override could break silently. Consider documenting this pattern clearly or exploring whether there's a more stable approach (e.g., creating custom utility classes for light-mode gradients).
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@src/input.css` around lines 353 - 358, The rule targeting :root[data-theme='light'] [class~='bg-gradient-to-br'][class~='from-white'] directly overrides Tailwind internal CSS variables (--tw-gradient-from, --tw-gradient-to, --tw-gradient-stops) which is fragile; replace this by defining a stable custom utility or theme extension in your Tailwind config (or a gradient plugin) that produces the desired light-mode gradient, or at minimum add an inline comment documenting why the internal variables are overridden and a TODO to migrate when Tailwind changes; reference the selector and the variables (--tw-gradient-from, --tw-gradient-to, --tw-gradient-stops) when making the change so you update or remove this CSS if Tailwind’s gradient implementation changes.
407-465: 🏗️ Heavy liftConsider refactoring components to use theme variables instead of utility overrides.
These 50+ lines of class-specific overrides (e.g.,
button[class~='text-slate-400'],[class~='hover:bg-white/5']:hover) work but indicate that components are using hard-coded Tailwind utilities rather than the theme variables you've defined. Each new utility combination requires another override rule, making this list grow over time.Why this matters: As you add more components or modify existing ones, you'll need to keep adding overrides here. This creates a maintenance burden and makes the theme system less cohesive.
Better approach: Update components to use theme classes (
.theme-text-muted,.theme-surface-strong, etc.) or theme CSS variables (var(--theme-text-muted)) directly. This way, theme switching "just works" without needing to patch individual utility combinations.Example refactor: Instead of
.text-slate-400→ override in CSS, use.theme-text-muted→ automatically themed.Since this PR focuses on quick visual improvements, these overrides are acceptable for now, but plan to refactor components in a follow-up to use the theme system consistently.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@src/input.css` around lines 407 - 465, The CSS file contains many hard-coded Tailwind-utility overrides (e.g., selectors like button[class~='text-slate-400'], [class~='hover:bg-white/5']:hover, [class~='bg-indigo-500/20'], [class~='text-slate-300'], and :root[data-theme='light'] [class~='rounded-xl'][class~='border'][class~='border-white/10']) that patch theme behavior per-utility; refactor by updating components to use theme-aware classes or CSS variables (for example replace usages of .text-slate-400, .hover:bg-white/5, .text-indigo-300, .bg-indigo-500/20, .text-slate-300, and the rounded-xl.border composite component) so styles read from var(--theme-*) or .theme-* utility classes instead of requiring these overrides, then remove the corresponding override rules from this file; implement this as a follow-up change across Button, LinkDropdown, and any components emitting those utility classes.
250-286: ⚡ Quick winConsider whether all dark backgrounds should be overridden in light mode.
This blanket override forces every dark background utility (
bg-slate-950,bg-slate-900,bg-gray-900, etc.) to use--theme-surface(white) in light mode. While this ensures consistency, it may break intentional design choices where dark elements should remain dark (e.g., code blocks, badges, or accent elements).Review your components to verify that no dark backgrounds need to preserve their original color in light mode. If certain elements should stay dark, you'll need to exclude those specific class combinations from these selectors or add back their original colors with higher specificity.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@src/input.css` around lines 250 - 286, The current blanket rule (:root[data-theme='light'] [class~='bg-[`#020617`]'], :root[data-theme='light'] [class~='bg-slate-950'], ... , :root[data-theme='light'] [class~='bg-gray-800']) forces all dark background utilities to use --theme-surface in light mode and may inadvertently override intentional dark elements; narrow the scope by (a) removing this global selector and only listing the specific utility classes you actually want to neutralized, or (b) add explicit exclusions (e.g., using :not(.preserve-dark) or excluding component classes like .code-block, .badge) to the selector, or (c) increase specificity for components that must remain dark (add a .preserve-dark class and set their bg back explicitly) so that --theme-surface only applies to intended elements instead of every bg-slate-/bg-gray-900 utility.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Nitpick comments:
In `@src/input.css`:
- Around line 353-358: The rule targeting :root[data-theme='light']
[class~='bg-gradient-to-br'][class~='from-white'] directly overrides Tailwind
internal CSS variables (--tw-gradient-from, --tw-gradient-to,
--tw-gradient-stops) which is fragile; replace this by defining a stable custom
utility or theme extension in your Tailwind config (or a gradient plugin) that
produces the desired light-mode gradient, or at minimum add an inline comment
documenting why the internal variables are overridden and a TODO to migrate when
Tailwind changes; reference the selector and the variables (--tw-gradient-from,
--tw-gradient-to, --tw-gradient-stops) when making the change so you update or
remove this CSS if Tailwind’s gradient implementation changes.
- Around line 407-465: The CSS file contains many hard-coded Tailwind-utility
overrides (e.g., selectors like button[class~='text-slate-400'],
[class~='hover:bg-white/5']:hover, [class~='bg-indigo-500/20'],
[class~='text-slate-300'], and :root[data-theme='light']
[class~='rounded-xl'][class~='border'][class~='border-white/10']) that patch
theme behavior per-utility; refactor by updating components to use theme-aware
classes or CSS variables (for example replace usages of .text-slate-400,
.hover:bg-white/5, .text-indigo-300, .bg-indigo-500/20, .text-slate-300, and the
rounded-xl.border composite component) so styles read from var(--theme-*) or
.theme-* utility classes instead of requiring these overrides, then remove the
corresponding override rules from this file; implement this as a follow-up
change across Button, LinkDropdown, and any components emitting those utility
classes.
- Around line 250-286: The current blanket rule (:root[data-theme='light']
[class~='bg-[`#020617`]'], :root[data-theme='light'] [class~='bg-slate-950'], ...
, :root[data-theme='light'] [class~='bg-gray-800']) forces all dark background
utilities to use --theme-surface in light mode and may inadvertently override
intentional dark elements; narrow the scope by (a) removing this global selector
and only listing the specific utility classes you actually want to neutralized,
or (b) add explicit exclusions (e.g., using :not(.preserve-dark) or excluding
component classes like .code-block, .badge) to the selector, or (c) increase
specificity for components that must remain dark (add a .preserve-dark class and
set their bg back explicitly) so that --theme-surface only applies to intended
elements instead of every bg-slate-/bg-gray-900 utility.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yml
Review profile: CHILL
Plan: Pro Plus
Run ID: b55f8dd6-d383-45fe-b8e8-5c9306e9b92c
📒 Files selected for processing (1)
src/input.css
kanikasharma-18
force-pushed
the
feature/improve-light-mode-ui
branch
from
51da823 to
09e7cf1
Compare
|
@adityapaul26 Please review my pr. |
There was a problem hiding this comment.
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
src/input.css (1)
322-334:⚠️ Potential issue | 🟡 Minor | ⚡ Quick winMake scrollbar track theme-aware in light mode.
The thumb moved to blue, but the track is still hardcoded dark (
#0f172a), so light mode gets a high-contrast dark rail that breaks visual consistency.🎯 Proposed fix
* { scrollbar-width: thin; - scrollbar-color: `#0ea5e9` `#0f172a`; + scrollbar-color: `#0ea5e9` var(--theme-surface-muted); } @@ *::-webkit-scrollbar-track { - background: `#0f172a`; + background: var(--theme-surface-muted); }🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@src/input.css` around lines 322 - 334, The scrollbar track is hardcoded to a dark color in the *::-webkit-scrollbar-track rule, causing contrast issues in light mode; make the track theme-aware by switching it to a CSS variable and using theme-specific values (e.g., define --scrollbar-track in :root and override in .dark or [data-theme="dark"]) and then reference that variable in *::-webkit-scrollbar-track; also ensure the global * { scrollbar-color: ... } uses the corresponding variables (thumb and track) so both standard and WebKit scrollbars respect the light/dark theme.
🧹 Nitpick comments (1)
src/input.css (1)
345-385: ⚡ Quick winAvoid brittle Clerk CSS selector overrides—use
appearance.elementsinsteadThese overrides in
src/input.css(345-385) target deep, Clerk-rendered DOM/class structure selectors (e.g..cl-profileSection__emailAddresses .cl-badge,.cl-menuButton) with!important. Clerk’s docs recommend treating such non-API selectors as unstable across UI updates—prefer configuring the same styling throughappearance.elements(or only target classes explicitly marked “safe to rely on” via Clerk’s inspector/appearance guidance).🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@src/input.css` around lines 345 - 385, The current CSS overrides target fragile Clerk-internal classes (.cl-avatarImageActionsUpload, .cl-profileSection__emailAddresses .cl-badge, .cl-profileSection__activeDevices .cl-badge, .cl-profileSection__emailAddresses .cl-menuButton, .cl-profileSection__connectedAccounts .cl-menuButton) using !important; remove these rules and move the styling into Clerk's supported appearance API (appearance.elements) or use only Clerk "safe to rely on" selectors from their inspector. Concretely, delete the CSS blocks referencing .cl-avatarImageActionsUpload, .cl-profileSection__emailAddresses .cl-badge, .cl-profileSection__activeDevices .cl-badge and the .cl-menuButton rules, and add equivalent entries in the Clerk appearance.elements configuration to set color, borderColor and background (and hover variants where supported) so the accent color is applied via Clerk's supported customization rather than fragile global overrides.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Outside diff comments:
In `@src/input.css`:
- Around line 322-334: The scrollbar track is hardcoded to a dark color in the
*::-webkit-scrollbar-track rule, causing contrast issues in light mode; make the
track theme-aware by switching it to a CSS variable and using theme-specific
values (e.g., define --scrollbar-track in :root and override in .dark or
[data-theme="dark"]) and then reference that variable in
*::-webkit-scrollbar-track; also ensure the global * { scrollbar-color: ... }
uses the corresponding variables (thumb and track) so both standard and WebKit
scrollbars respect the light/dark theme.
---
Nitpick comments:
In `@src/input.css`:
- Around line 345-385: The current CSS overrides target fragile Clerk-internal
classes (.cl-avatarImageActionsUpload, .cl-profileSection__emailAddresses
.cl-badge, .cl-profileSection__activeDevices .cl-badge,
.cl-profileSection__emailAddresses .cl-menuButton,
.cl-profileSection__connectedAccounts .cl-menuButton) using !important; remove
these rules and move the styling into Clerk's supported appearance API
(appearance.elements) or use only Clerk "safe to rely on" selectors from their
inspector. Concretely, delete the CSS blocks referencing
.cl-avatarImageActionsUpload, .cl-profileSection__emailAddresses .cl-badge,
.cl-profileSection__activeDevices .cl-badge and the .cl-menuButton rules, and
add equivalent entries in the Clerk appearance.elements configuration to set
color, borderColor and background (and hover variants where supported) so the
accent color is applied via Clerk's supported customization rather than fragile
global overrides.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yml
Review profile: CHILL
Plan: Pro Plus
Run ID: fc8f58e1-88fc-48fe-b5fc-825dd207fec7
📒 Files selected for processing (1)
src/input.css
2 participants
Pull Request Summary
This PR improves the light mode theme of AlgoScope by refining the design system for better visual consistency, readability, and modern UI polish. The changes ensure that light mode feels as refined as dark mode while preserving all existing functionality.
What changed?
Closes #347
The existing light mode lacked cohesion and modern visual structure compared to dark mode, resulting in reduced readability and visual clarity in some areas. These improvements make the light theme more comfortable for extended use, especially in bright environments, and bring it closer in quality to the dark mode experience.
Type of Change
feat- New user-facing feature or algorithm capabilityfix- Bug fix or regression fixdocs- Documentation-only changestyle- Formatting or styling change with no behavior changerefactor- Code restructuring with no feature or bug-fix behavior changeperf- Performance improvementtest- Test coverage or test infrastructure changebuild- Build system, dependency, or packaging changeci- GitHub Actions, Docker, Vercel, or release automation changechore- Maintenance change that does not affect usersrevert- Reverts a previous changeRelease Notes
Release note category:
Release note entry:
Testing and Verification
npm ciornpm installnpm run format:checknpm run lintnpm run buildhttp://localhost:5173UI Evidence
Before:
After:
Summary by CodeRabbit