fix: scope un-themed editor color fallback so dark-mode ramp wins - #9754
fix: scope un-themed editor color fallback so dark-mode ramp wins#9754Liewzheng wants to merge 1 commit into
Conversation
The web and space apps each keep a plain :root fallback block of editor color variables (light values) for the pre-theme window. Bundled CSS orders these blocks after the editor package's [data-theme*=dark] rules, and at equal specificity the later rule wins, so the fallback overrode the dark ramp in every theme. Scope the fallback with :not([data-theme*=light]):not([data-theme*=dark]) so it only applies before a theme lands (and for custom themes that match neither selector), letting the themed ramps take over otherwise. Fixes unreadable light text on light sticky backgrounds in dark mode.
◈ PR Lens
Architecture 2 components touched across 1 lane. Data flow No data-flow sequence changed in this PR. Drill down
|
|
|
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Team Run ID: 📒 Files selected for processing (2)
Included review availability: Your plan provides up to 10 included reviews per hour; 9 remain after this review. 📝 WalkthroughWalkthroughBoth application stylesheets scope the unthemed editor color fallback to roots without light or dark theme attributes. This prevents the fallback variables from overriding themed editor color ramps. ChangesEditor color fallback
Estimated code review effort: 1 (Trivial) | ~2 minutes Merge Risk: ⚪ Minimal · up to Dark-mode editor consumers can use their dark color ramps without fallback backgrounds overriding them, while unthemed and custom themes retain fallback behavior. No current merge-blocking risk remains. 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
Full details: Description checkExplanation The description is complete and relevant. It explains the root cause, the fix, preserved custom-theme behavior, test scenarios, formatting validation, and linked issue. No screenshots are needed because this is a styling fix with documented computed-color verification. Full details: Docstring CoverageExplanation No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check. Docstring coverage is scoped to functions touched by this diff. Analyzed 0 functions across 0 files. (2 skipped: 2 unsupported.) ✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Description
Fixes stickies (and any other consumer of
--editor-colors-*-background) rendering with light pastel backgrounds in dark mode, making their light text unreadable.Both
apps/web/styles/globals.cssandapps/space/styles/globals.csskeep an un-scoped:rootfallback block of editor color variables (light values) for the pre-theme window. In the bundled CSS these blocks are ordered after@plane/editor's[data-theme*="dark"]ramp; at equal specificity the later rule wins, so the light fallback overrode the dark ramp in every theme.The fix scopes the fallback with
:not([data-theme*="light"]):not([data-theme*="dark"]), so it only applies before a theme lands and forcustomthemes (next-themes ships acustomtheme matching neither selector — deleting the block outright would leave those variables undefined there).Type of Change
Test Scenarios
rgb(88, 62, 42)for orange,rgb(31, 73, 92)for light-blue) with light, readable text.rgb(255, 227, 205)for orange + dark text) — the fallback block's values are value-identical to the editor package's[data-theme*="light"]ramp, and the:not()scoping never matches once a theme is applied.npx oxfmt --checkpasses on both modified files.References
Closes #9753
Summary by CodeRabbit