Hacker News new | past | comments | ask | show | jobs | submit login

This is a good corner cut, but in addition to other comments, there's two huge accessibility concerns, and one usability/design principle problem:

1. The color spaces available in CSS are not perceptually uniform. You may achieve some a11y checkbox with the inversion of luminosity/hue, but that doesn't mean it's actually readable.

2. Not all, but many, dark mode users prefer lower contrast in some areas to reduce brightness over all. This approach can tailor in the opposite direction.

3. In general with dark themes, it's still generally preferable for darker-in-light-mode things to be darker in dark mode. This does the opposite and can lead to confusing design structure.




These are all great points for anyone looking to try this to keep in mind.

For us, on points 1 and 2, we have done some due diligence on going through all the different pages/flows on our dashboard to make sure everything still looks good and text remains readable. A lot of folks internally prefer dark mode and dogfood it day to day which also helps a lot. So far we also haven't heard any major complaints re: readability/contrast from our customers, thankfully, but of course as soon as we do, we'll adjust and re-evaluate.

On point 3, this is where the inverse filter trick comes in handy, we've had to apply this in a few places where the inversion made things look awkward and/or unusable, most notably external partner logos and user-uploaded receipt pictures.

All of this is part of why it's still labeled as an experimental feature even months after release.


I’m super curious how much effort has gone into evaluating what works and making adjustments. I’m not trying to poo poo the idea if it’s working and doesn’t have a noticeable performance impact.

I know when I came back to web dev a year ago after five years fully backend this is exactly the idea I wanted to try. I asked the advice of a friend who’d stayed FE as dark mode rolled out and he said, basically it’s more trouble than it’s worth. I took that advice and built a dedicated dark mode for the project at that time. And I did so for my personal site which is a fairly intricate labor of design love (link in profile).

Honestly it was hardly any additional effort, and it wasn’t an afterthought. I prefer light mode generally but I like my own site’s dark mode better almost across the board. But there were so many details that I think would have been more work, and probably more difficult work, if I tried to start with filters and adjust.

FWIW, I don’t use it throughout but I do use it where I wanted programmatic control of color: I highly encourage looking at HSLuv or another perceptual color space to handle some of this.


The whole thing has been fairly hands-off for us, surprisingly enough, as I fully expected this to be a maintenance nightmare that we might have to pull back, hence the experimental label. I could count on a single hand the number of times we had to make adjustments since we shipped it.

I'd honestly love to be able to implement dark mode the proper way with semantic color tokens and runtime theme swapping someday. But since our codebase didn't start with hot-swappable theming in mind, retrofitting a proper theme-based dark mode into it would be a gigantic undertaking that we'd have trouble justifying against all of our other priorities.

For anyone building a brand new app, definitely start by implementing themes the right way instead of using this hack. You'll definitely save yourself a lot of headache down the line.


> But since our codebase didn't start with hot-swappable theming in mind

But it doesn’t have to be that thought out. It just needs the same kind of symmetry you’ve applied, wherever you’ve applied colors (and maybe lighten font weight a bit). You can just use a media query and target the same selectors.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: