Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[v5] Dark theme: inconsistent visual depth (color inversion) #6815

Open
medienbaecker opened this issue Nov 26, 2024 · 3 comments
Open

[v5] Dark theme: inconsistent visual depth (color inversion) #6815

medienbaecker opened this issue Nov 26, 2024 · 3 comments

Comments

@medienbaecker
Copy link
Contributor

After discussing this in Discord a few times already, I'm creating this issue to centralize the conversation about Kirby's new dark theme.

Kirby's new dark theme has a problem with visual depth perception due to simple color inversion.

While some elements like the sidebar maintain consistent depth across themes (appearing darker in both), other elements like inputs and textareas lose their visual depth. In the light theme they are lighter, making them appear closer to the user. In the dark theme they are darker, making them seem further back. While the black dropdowns work just fine in the light theme, using white dropdowns in the dark theme breaks the "dark" theme concept.

I do understand the intention behind inverting the colors. It's seemingly easier, making sure third-party plugins "just work". But I'm afraid it might not be worth it. Many plugin's I've tested need some manual adjustment anyway. There's even core UI elements that need color overrides — like the tabs getting darker/transparent when they're active. In my opinion this "shortcut" is not worth it.

Here's Kirby's light theme:

neustart test_panel_pages_test (3)

Here's Kirby's dark theme:

neustart test_panel_pages_test (4)

Here's a first, rough idea of how the dark theme could look with consistent depth:

neustart test_panel_pages_test (6)

I'd gladly spend more time on this to make an actual design, but only if you're interested in the general idea. For now, I've just played around with the variables a bit in dev tools.

@distantnative
Copy link
Member

Thanks a lot, having this feedback centralized and even mockups is super helpful.

I don't think I agree with the notion that it wouldn't be worth it otherwise. That's a too binary perspective for my taste. I see it more as a process and progression, where our current version isn't the ideal but somewhere in the middle. And for 5.1 or so we can get better with your suggestions as another step along this progression.

@medienbaecker
Copy link
Contributor Author

I understand the approach, but I'm worried about losing momentum. Plugin developers are currently adjusting their plugins for the dark theme. If you change the fundamental approach later, they'll need to adapt again. A "real" dark mode will most likely introduce breaking changes.

One thing to consider: the dark theme is not opt-in but automatically active when you use a dark OS while the theme dropdown is hidden in the account page.

@bastianallgeier
Copy link
Member

I think we can already take some good first steps from this:

  • Maybe it would be better to turn the dark mode into an opt-in feature, even if the OS is set to dark.
  • As far as I can see, it all really boils down to one major new adjustment and that would be a better differentiation of backgrounds and to think of this in layers. Maybe something like this:
--color-background-input: 
--color-background-body: 
--color-background-menu:
--color-background-item: 
--color-background-button: 

This would be inconsistent between dark and light mode and not simply inverted. We probably find more places where we need such descriptive colors later. But for now, this could already replicate Thomas' suggestion, feel pretty future-proof and would still not turn everything on the head.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants