Improve dark mode styles across multiple pages #2125
Reference in New Issue
Block a user
Delete Branch "fix/dark-mode-contrast"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
While using the app in dark mode, I noticed that in some places the text was hard to read or not visible at all due to low contrast.
This PR adjusts the styles on several pages to improve readability — mostly by tweaking background and text colors where the contrast was too low. I tried to stick to the existing theme and keep things consistent.
Let me know if you'd like any changes!
Also, let me know if you’d like a short video demo — happy to record one if it helps!
Patchset for more fixes
Before
After
@menaguilherme
Updated patch for more fixes
@neo773 Thank you for taking the time to update the patch — I’ve applied the changes and pushed them!
Thanks for these fixes, appreciate it!!
We're very much a WIP when it comes to design system, but I've published a little reference here that might help with this PR:
https://github.com/maybe-finance/maybe/wiki/Design-System
There are 2 main areas that I think we need to address (have left some contextual comments throughout):
dark:some-style(see doc above)Other than those two points this looks good!
We'll want to use our Figma tokens (rather than
bg-divider-adaptive) here (see doc I posted)@@ -1,7 +1,7 @@<%# locals: (accountable:) %>We'll want to rely on our centralized
maybe-design-system.cssto define these hover/focus states in each "mode" to avoid the pseudo selectorsdark:*in the views.These selects/inputs should already be receiving styles from our centralized form builder, so we can update things there to centralize everything.
@@ -1,5 +1,5 @@<%= render "layouts/shared/htmldoc" do %>this is not the right background color it conflicts with primary button, needs to be pure black
@@ -1,5 +1,5 @@<%= render "layouts/shared/htmldoc" do %>Thanks for pointing that out! I’ll revert that part and bring back the original background to avoid any conflicts. Appreciate the heads up!
@zachgoll All feedback addressed — removed all
dark:usages, replaced them with design tokens, and updatednumber_fieldanddate_fieldto use theStyledFormBuilder.Still a bit unsure how to best handle the
bg-divider-adaptivecases — I reintroduced the utility in one spot where the token replacement didn’t quite work visually. Open to suggestions if there’s a better direction.Appreciate the guidance!
Looking good!
Just a few details to finish things up:
class: "..."overrides in a few forms that I think we can remove and just leverage our form builder styles forIn regards to
bg-divider-adaptive, just spoke with @justinfar and he said for "dividers", we should be using those "border" utilities.In this case, since we have
divelements representing dividers, I think the most natural way to implement this is to switch those over to<hr>elements with that border. Does that work?I think these can move up to the metaprogramming block we have here, as both number/date fields are captured there:
a7dfafc907/app/helpers/styled_form_builder.rb (L6-L16)I think this needs to be removed? This form should be using
styled_form_with. Unless there was a specific reason to override that I'm not seeing?Similar to comment above, think we can leverage the global form builder styles here?
@zachgoll All feedback addressed — removed redundant
class:usage from form fields, movednumber_fieldanddate_fieldinto the builder’s metaprogramming block, and replaced thebg-divider-adaptivedividers with semantic<hr>elements usingborder-secondary.Apologies for the extra back-and-forth — I missed a few things earlier but really appreciate the clear direction and your patience throughout. Let me know if there’s anything else I should adjust!
No worries! Just a few more little edits and we should be good.
To get those checks passing locally, you can use the following commands:
We can delete this and replace all usages with
bg-containerSorry to backtrack on this, but after seeing the final changes I don't think we need to make any changes to this file at all. Let's just make sure
form-field__inputhas all the classes needed in the main design system CSS file and we should be good to go.That way, whether we're using a form builder or manually passing in
form-field__input, we'll get the same styling result.So in summary:
text-ellipsis placeholder:text-subdued@@ -1,5 +1,5 @@<%= render "layouts/shared/htmldoc" do %>@@ -1,5 +1,5 @@<%= render "layouts/shared/htmldoc" do %>Hey @zachgoll , I applied the bg-container change and it works well overall, but I noticed some contrast issues in dark mode, especially for layered components like this budget setup step.
Here’s a comparison between light and dark mode with the current tokens applied:
📸 Light mode:

🌒 Dark mode:

In dark mode, the progress bar and surrounding sections feel a bit flattened — it’s hard to visually distinguish the layers (e.g., background vs. container vs. progress track), which impacts readability and hierarchy.
I reviewed the tokens in maybe-design-system.css and tried options like bg-surface, bg-overlay, bg-container-inset, etc., but couldn’t find a combination that resolved the contrast issue effectively.
That said, it’s possible I missed a better combination or intended use of those tokens.
Is there a visual reference or Figma spec I could check to understand how these background layers should be applied in cases like this?
Just want to be sure I’m staying within the system and not introducing anything unintended. Appreciate any guidance!
Hey @zachgoll – I applied the requested changes and ran the linters you mentioned (
rubocop,erb_lint,brakeman). Let me know if anything else is needed!Thanks again for your time reviewing this 🙏
Looks great. Thanks for your work on this!