Show HN: Darken – Darkmode Made Easy
github.com
github.com
Have a read of an article such as this one, and be smart about colour translation. You might need to calculate contrast or offer a contrast setting as a minimum, and watch for shadows.
https://uxdesign.cc/turn-the-lights-off-designing-the-dark-m...
Side note: I've been really happy with the "Dark Reader" plugin on various browsers. Have a look at it and see how it handles brightness (+/-) and contrast (+/-).
he doesn't invert colours.
I hope it make the thing more clear.
I like to use dark schemes for coding because I get access to more colors and the lines are short and spaced. But for reading a paragraph more than just changing the text color is needed, and none of the sites does that.
So the sites having it toggleable would actually be quite cool. I hope browsers will get a possibility to check/uncheck this per-site.
The only big downside I've seen so far is performance, but I haven't quantified it yet.
[0] https://github.com/darkreader/darkreader#using-for-a-website
It's hard to explain, but the white background feels like, psychologically "freeing" - if that makes any sense. It feels like everything is "open" and "fresh".
Dark mode feels like being in a cave.
in Visual Studio Code settings.json edit those line : "workbench.colorTheme": "Default Light+","workbench.colorCustomizations": { "editor.background": "#e0ffec", },
Do you spot bugs more easily in the greenery?
[0] https://kitemaker.co [1] https://blog.superhuman.com/how-to-design-delightful-dark-th...
In the beginning there was invert colors. Then came smart invert - it worked with some things, failed with others, but was generally pretty good.
Dark mode (by way of prefers-color-scheme etc) should make things awesome in the long run, but at least for now all that's happened is to keep things dark I have to juggle fucking THREE different switches - and end up having to fall back to classic invert most of the time. Smart invert basically stopped functioning with iOS 13.
Properly implemented they could've had a fallback css override a la DarkReader and just put an extra switch per-website, crowdsourcing the results, as well as keep their own database/system override for lazy developers with already-dark apps who refuse to respect wishes (nudge nudge, Spotify...).
Ok, this is ranty, but this is such a weird regression touted as a "feature". Poor form.
FTFY
But I disagree that Apple should be doing all the work, I really don't want them pushing their design opinions even further upon us (no matter how great they might be)
Not sure if this exists yet (although I think I've seen it before); a CSS parser that will automatically generate all the correct media queries to have a dark mode. Done by smartly inverting colours, possibly giving the chance to quickly override them yourself.
None of it is perfect. I know programmers believe anything that's not software or brewing a flat white should be automated, but dark designs are inherently difficult because the pleasant ridge is narrow, with contrast always close to being too high or too low. As of yet, it really need a designer's eye.
https://litmus.com/blog/the-ultimate-guide-to-dark-mode-for-... is a good article about this. We just released this sort of functionality for Fastmail’s webmail within the last few days, too, matching what Litmus calls a partial colour invert. We find that it doesn’t satisfy quite everyone, but the overall experience is much improved. I myself use light mode for my work email and dark for my personal email (partly to distinguish them, partly so I’m testing it—otherwise I’d prefer light mode), and this general approach has produced very good results in all but one case I’ve experienced so far (and that one was still acceptable).
It allows you to build dark mode optimized email, and when you preview the email in dark mode, the whole app changes to dark mode.
Because of this we use a manual toggle instead of prefers-color-scheme.
We picked the colors carefully and changed things like shadows borders etc to make the interface look great in dark mode. Although a solution like OPs could be a quick and dirty way to get a basic dark mode implemented, you'll never get your site or app looking quite as good as getting a designer to look at it.
It's a way to keep people up at night to show them more ads more frequently.
People who aren't insane and who sleep at night have a good lighting in their environment and a light theme.
Personally I prefer light themes, I just turn the lights on so that I don't sit in the dark.
Here you also have the class based custom styles but also have a CSS variables based styling system. You can chose what value will take a variable depending on the current state of the darkmode.
See the readme of the github page for more informations, ask again if you need additional informations.
A simple github page showing a demo with the code next to it might be cool, and the README size can be cut in half.
As a demonstration of the alternative approach I advocate, see what I came up with for my own website: https://chrismorgan.info/blog/dark-theme-implementation/. This uses native CSS techniques, working completely without JavaScript, merely using JavaScript to allow the user to manually switch, retaining that preference for future page loads and optimising page loading just about as far as is possible when doing it client-side to minimise the probability of a flash of inverted content if you manually switched to the opposite of what (prefers-color-scheme) would have chosen.
The main thing that my approach doesn’t do that this thing does is dispatching an event, so that other JavaScript could conveniently be notified of a theme change. This is fairly deliberate on my part (I deliberately do all theme switching with CSS, and have no JavaScript that needs to change anything for dark mode), but could readily be added to what I wrote if desired.
With my approach (for which I will also clarify that the JavaScript is deliberately written for compactness, not some theoretical notion of maintainability or extensibility), the example:
<button id="dm-toggle">Toggle darkmode</button>
<script>
const darkmode = new darken({
toggle: "#dm-toggle",
variables: {
"--primary-color": ["#ffffff", "#000000"],
"--secondary-color": ["#000000", "#ffffff"],
}
});
</script>
… would be written more like this: <script>
// (Add the button to the document in JS,
// since it’ll only work if this JS runs anyway.)
</script>
<style>
body {
--primary-color: #ffffff;
--secondary-color: #000000;
}
</style>
<style media="screen and (prefers-color-scheme: dark)">
body {
--primary-color: #000000;
--secondary-color: #ffffff;
}
</style>
(Two style blocks because my thing doesn’t deal with `@media … { … }` inline in CSS, because I don’t need it. You could make it do it if you really wanted to.)I find this approach much more manageable, and it allows adding custom CSS rules for dark mode (which I definitely use), rather than just setting CSS custom properties.
Where I could see this being useful is that you have a callback that you can use, so when dark mode is enabled, you can make some other adjustments when needed.
Here is an example: https://colinespinas.github.io/darken/
[1] https://support.apple.com/en-ca/HT208976
[2] https://css-tricks.com/dark-modes-with-css/
[3] https://developer.mozilla.org/en-US/docs/Web/CSS/@media/pref...
It does not use `prefer-color-scheme` for now but I'm planning to add the option later.