grist-core
grist-core copied to clipboard
Dark mode overrides choice text color
Describe the current behavior
If I have a choice options configured like so:
And then I flip it to dark mode, it looks like this:
The text color has flipped to white, but the background color hasn't flipped.
If I manally set the text color to black, it will stay, but using the default black causes it to flip.
Steps to reproduce
No response
Describe the expected behavior
It should either keep a default black or flip the background color as well.
Where have you encountered this bug?
- [ ] On docs.getgrist.com
- [X] On a self-hosted instance
Instance information (when self-hosting only)
-
Grist instance:
- Version: c58dbfc689f90197d970b021f0a1505668122e793983e11bba2112596256d2da
- Installation mode: Kubernetes
- Architecture: single-worker
-
Browser name, version and platforms on which you could reproduce the bug: Arc
Hi, this is also giving me big issues.
I can switch to light mode, but I have a crowd sourced tables and: Grist defaults to dark mode when the browser/OS is set to dark mode, meaning visitors can't see things. have many big tables filled with 'Choices' tags. And they become illegible. I can change the default text colours to make it legible in dark mode, but this will take hours.
Here's a screenshot:
Hi can anyone help with this issue at this time?
@georgegevoian @manuhabitela any ideas for better behavior here?
@georgegevoian @manuhabitela any ideas for better behavior here?
If we had a light and dark variant of text color, we could compute the WCAG contrast ratio for both against the background color, and pick the better of the two.
Themes will soon define a base white and black color - perhaps we can add a new variable like textWhite, and use that alongside the existing text variable as the two variants. @manuhabitela wdyt?
Setting an explicit text color for the light-background choices seems the only option short-term. (This should be doable via API, with a bit of scripting and relying on some undocumented structures.)
I wanted to mention that along the way of working on accessibility, there is a design for a different color-picker for things like choice colors. This design offers a choice of pairs of colors (rather than separately background and foreground), and includes in particular dark-and-light variants for a list of recommended color-pairs. See https://github.com/gristlabs/grist-core/issues/1006 and this design. There is no ETA on this yet, however, since other projects have priority.
Okay, for the meantime, my workaround is https://darkreader.org/ extension.
First thought:
In case a choice background color is set, but no text color is, I guess the dumb "fix" for now would be to force text color to stay always black, even in dark theme (only when the bg is set)?
It's not a great solution because this makes the assumption the background color is set by the user first when in light theme. Pushing this would break colors for people who chose a bg color relying on the default dark theme text color.
Second thought:
When applying colors in ChoiceToken, if background color is set but no text color is, have the text color automatically find the closest black/white shade matching WCAG. I guess this is a good fix?
I tried a quick implementation of the second thought, will show you something soon.
PR is open https://github.com/gristlabs/grist-core/pull/1529, if any of you is interested @dsagal @georgegevoian @paulfitz.
Thanks so much for this, looking much better, just noticed one thing missed:
When Grist is set to dark mode, double clicking a cell to edit "choices" that part of the UI doesn't conform to the new dark mode colours, Meaning one can't see what they're removing or what's already selected.
Good catch, woops!
Good catch, woops!
I see it's not fixed yet so just checking that it's been remembered, should this issue be re-opened?
Sorry man, I was away a little during summer, this is still in my head, I'll try to take care of that this week or next week 🤞
I'll try to take care of that this week or next week 🤞
No rush, thanks, just wondered if it may have gone un-noted