Dark mode in a website with CSS | Hacker News Reader

Dark mode in a website with CSS

tombrow.com

491 pointsteaspoon189 comments

I recently added dark-mode support to a few sites. It took way more time then I thought it would. At first I thought "oh just add a few lines off CSS" but then ...

* Some diagrams had white backgrounds

Solution: remove the backgrounds so they are transparent

* Most diagrams had black lines/arrows which didn't look good on dark gray backgrounds

Solution: use CSS filter:invert for images

* Some images are photos not diagrams so inverting their colors doesn't work

Solution: Use a selector for svg only img[src$=.svg] and a class when manually needed

* Some svg diagrams have their colors referred to like "see the red object" in that text.

Solution: filter: invert(1) hue-rotate(180deg);

That makes the blacks become white but the colors kind of stay the same hues at least

* The are many interactive digrams on the sites.

Solution: All of those had to be refactored to not use hard coded colors but do something like

    const darkMatcher = window.matchMedia("(prefers-color-scheme: dark)");
    const isDarkMode = darkMatcher.matches;
    const colors = isDarkMode ? darkColors : lightColors;

And draw everything with the appropriate colors. Its up to you if you want to trigger re-drawing if the user changes their preference

* Some text was color coded for to match the diagrams as in

    <span style="color: red;">x-axis"</span>

But now those colors looked bad on a dark background.

Even 5 months later I still find places I missed.

Why mess with content colors? Just leave the images.

The problem is very simple: if you have diagrams with black lines on transparent background it doesn't work with dark background. Many colour choices we do make less sense for dark backgrounds than for light ones. The comment above properly describes the breadth of real problems you might face.

The easy option is to just put a white background behind the diagrams. It might not be as pretty as having the image designed right for a black background but its better than that hack.

that can be like a lighthouse in a dark night. flux can help of course, but if you are serious about supporting dark mode then you should eliminate as much white space as managable.

I think he means if you're serious about dark mode then design two graphs one light, one dark. Solving "how do I turn a well designed light mode image into a dark mode image" is an AI task that would be a nice research paper, not something a designer can hack together with a bunch of if-then rules.

I would have thought so to but looking at the white background digrams on the dark pages was a horrible experience. It pretty much defeated the entire purpose of having a dark mode as there was these bright white diagrams shining in my eyes.

Which is better you can compare

Here's before dark mode

https://codepen.io/greggman/full/vYYOxjd

Here's leaving the backgrounds to the diagrams white

https://codepen.io/greggman/full/zYYGZWB

And here's the hue rotated solution

https://codepen.io/greggman/full/abbOJYB

The ideal solution would be to make all the diagrams twice but that's a ton of work if your site has lots of diagrams. Of course it's all an opinion. I don't have time to redo all the diagrams or go make them CSS styled indivdually so this is the solution I chose for now.

Yeah, the hue rotation is really nice. Do you have a real example where it doesn't work?

If you have a lot of images with white backgrounds, that's going to defeat the purpose of Dark Mode.

Some people prefer dark mode because they suffer migraines and bright lights are a problem when they have a migraine. Or homeless people may be using it for both stealth purposes and battery conservation when they have limited opportunities to recharge.

For some people, this preference is not just some minor detail. It's a much more important thing than "I just happen to like dark color schemes."

Do you not think maybe that people with migranes and homeless people conserving battery might be edge cases just a little bit too far to worry about?

Because I do. And I'm someone who runs permanent dark mode via plugins in firefox due to eye strain/headaches. I don't expect the world to bend over backwards and I certainly don't expect people to recolour image backgrounds for me. The plugins do a good enough job.

In the U.S., more than 38 million people have migraine disease, with some estimates suggesting that this number may be even higher, impacting as many as 50 million or more. Some migraine studies estimate that 12 percent of adults in the U.S. population have migraine, and 4 million have chronic migraine.

https://migraine.com/migraine-statistics/

> Or homeless people may be using it for both stealth purposes and battery conservation when they have limited opportunities to recharge.

Sorry, what? I feel like this is a very contrived reason to support dark mode in your interface, if it even helps…

Contrived: deliberately created rather than arising naturally or spontaneously. Synonym: deliberate

created or arranged in a way that seems artificial and unrealistic. Synonym: forced

----

People can do anything they want with their websites. I'm not anyone who sets global policy on what your website should do.

But there's nothing contrived about the comment. It's an unplanned, spontaneous thought based on first-hand experience.

I spent nearly six years homeless. I'm quite open about that. I still blog about homelessness.

I spent a lot of time online while homeless. This was written about me:

http://alexandralindelof.com/story-package/

I'm aware of that, but images on a website being desaturated or having a dark background doesn't seem like it would help. (I do agree with your appeal to those who are sensitive to bright lights, FWIW. It's just that this one sounds like a bit of a reach.)

If you are illegally camped in a dark field and your phone, tablet or laptop is the only source of light, bright white images emit much more light that can give away your position than dark ones.

IIRC, the two primary things we did to conserve battery power were 1. Avoid certain games and 2. Turn down screen brightness.

In ordinary usage, the screen on our tablets was typically the biggest drain on the battery. This was especially true for tablets with a large screen.

I don't have (anec)data specific to dark mode on websites and power usage. I just know that using our devices carefully was the difference being kept occupied for three or four hours until we could sleep or running out after an hour and having nothing to do but talk, which is not a stealthy activity.

"As an example, one commercial QVGA OLED display consumes 0.3 watts while showing white text on a black background, but more than 0.7 watts showing black text on a white background, while an LCD may consume only a constant 0.35 watts regardless of what is being shown on screen."

https://en.m.wikipedia.org/wiki/AMOLED

So it depends on the display and may become a thing of the past.

That's really good info.

The citation was from 2009. I expect, or rather hope, that things have improved. Interesting link, by the way, and very useful to add to the discussion.

What about browser addons like Dark Reader? Would that make more sense than relying on thousands of sites to have a reliable dark mode (when the vast majority won't support any kind of dark mode anyway)?

I was internet acquainted for a time with someone suffering chronic migraines. She said she could not do anything with browsers most of the time and switching her phone to dark mode was a problem because it just flipped the colors for everything.

She spent her time on Twitter because it has a terrific dark mode. She couldn't get other things to work for her.

So people who are very photophobic are apparently not finding adequate accommodation for their needs. I poked around a bit after talking to her and confirmed that her criticisms were valid. The current available options don't work well for trying to surf the internet under such constraints.

I'm not advocating that anyone do anything in particular. I'm just talking about use cases I have a little knowledge of. That's it.

Sure. I'm wondering whether something like Dark Reader - i.e. an addon or even as a standard browser feature - might be more helpful to people who genuinely need dark mode everywhere, rather than trying to persuade thousands of site owners and designers to individually provide some kind of dark styling (and as is apparent in the thread, not doing so perfectly, e.g. with images).

>Solution: remove the backgrounds so they are transparent

This sucks when you want then share the diagram with someone, on certain platforms the diagram will be unreadable due to the lack of contrasting background.

It’s easier to add a background later than remove one after, so I think transparent bg is a good solution

You know the article addresses this exact problem? It links to another article focused on this problem, which suggests reducing the saturation of images: https://medium.com/dev-channel/re-colorization-for-dark-mode...

(It doesn't seem to have occurred to that author to try reducing the brightness of the images, or reducing saturation with the saturate() instead of grayscale(), but those also seem worth trying, brightness in particular.)

Apple's Smart Invert is even simpler, it just leaves media like images and video as-is, only inverting colors of other things.

I suppose for diagrams that you know are black-on-white, inversion is nice, but it should be opt-in.

Every time I think "oh just add a few lines off CSS" => 90% chance it'll take all day.

CSS needs an equivalent to an SQL query planner, so that mere humans can understand how it works.

The Firefox DevTools (currently in Nightly, soon in stable) have started at least telling you why a certain selector does not apply, which sounds incredibly helpful: https://twitter.com/FirefoxDevTools/status/11747010367930327...

> Solution: use CSS filter:invert for images

> Solution: filter: invert(1) hue-rotate(180deg);

This might be nominally acceptable, but it’s going to be pretty mediocre. Both of these methods dramatically distort color relationships from the original.

Getting someone to explicitly pick colors that work in dark mode will yield much better results. (Of course, takes a lot more manual work by an expert, instead of a few automatic text replacements.)

A agree 100% but didn't want to have to manually remake 150+ diagrams

Your comment makes me glad I don't do UI's. But then I'm reminded of a syntax highlighting scheme I wish existed:

You'd never define a particular color, just algorithms for taking some input color and deriving each needed color from that one.

Then the user can say: "I want this file in blue and this one in orange" and the syntax highlighting still calls out the features in a relative way but the absolute colors are used as cues for something else (like test coverage or something from source control).

Ok, maybe doing UI's would be fun after all.

The problem is our brains represent colour in a very weird way and the algorithms I’ve seen for this always look horrible. I guess maybe training a neural net on this might make the results more human!

No, what really helps is picking the right colour space to work in. Which is probably CIE-LAB, being constructed especially for the weird way our brains perceive colour, but still also works mostly correct if you treat it as a linear space.

I love dark mode as a user, but as a developer it terrifies me how much complexity is involved in programming in 2019. At a stroke, it doubles the number of possible combinations of:

- 2 device sizes: desktop vs mobile (e.g. responsive)

- 3 platforms: web vs iOS vs Android, or web vs Windows vs macOS vs Linux (not even counting cross-browser or OS version quirks), or god forbid all of the above

- 2 input methods: hover/click/drag vs tap/hold/swipe

- 2 modes for accessibility: full visual+audio vs screenreader/captioned

- And now 2 visual modes: light vs dark

That's 48 combinations to design and test for. I'm probably forgetting some too. But as a developer it makes just the baseline cost of any basic app so damned high.

Again, as a user I love it. But the entrance cost for entrepreneurs, or even hobbyists? Man oh man.

As developers, can't we use progressive enhancement to support as many scenarios as we want?

Conversely, that's what's amazing about the Web, right?

Whenever people introduce any of those things, like when iOS was introduced, they had to decide how to port all the existing content and interactions and widgets to mobile and touch interfaces. As a result, if an entrepreneur or hobbyist makes an app on one platform and wants it to be at least minimally usable on another platform, the Web way, way lowers the barrier to make that jump.

The particular methods for making CSS backwards compatible are specific to the web, but the general problems faced by having user display preferences are not. Adding these features to native apps blows up your testing matrix there, too.

In many ways, it's even worse. I've got OS settings here for "increase contrast", "reduce transparency", "use grayscale", "invert colors", and (because areas of native windows can be translucent) even the desktop wallpaper comes into play.

I turned on dark-mode for testing my own app, and I had to turn it off because there's parts of Xcode where the contrast ratio is less than 1.1:1.0. The text is downright invisible. Obviously nobody at Apple would ever intentionally make software like that. They must have simply never thought to test with the same settings as I have.

https://pbs.twimg.com/media/D1kfN6SUcAEwWxq?format=png&name=...

And yet Xcode is very successful and well-liked, or at least if it's hated, it's not for the flaw you found.

Doubtless many, many other apps have also made that same mistake, yet I highly doubt it has made the difference between success and failure for even a single one of them.

All of those OS features were introduced to help people, because people wanted them, some even needed them. I don't think we live in a worse world for having them, and I believe that dealing with features like those would actually be even harder in a world without the Web.

Imagine: the original idea used to be you'd just supply a reasonably-marked-up document and maybe some formatting suggestions and the browser/user would pick the colors and fonts and such.

And those browser set styles were disgusting so people decided to just style everything themselves

To be fair, the styles they chose were almost never any better than the defaults until the early 2000s or so (and even then it was hit-or-miss) by which time the dream of the web as hyperlinked documents the user could view as they pleased was falling out of fashion in favor of making it flashy brochureware and, soon after, a tightly specified app distribution platform.

I still remember how amazing Pepsi.com was in the mid-90s. They were doing tricks with images and tables even back then.

Okay, but they only did that because browsers put tools like CSS/JS in their hands to let them.

I think it was a bad choice on the browsers' part. It's a totally abdication of the browser's responsibility to render things nicely and configurably for the user. Worse, javascript is bundled malware: you're letting websites execute arbitrary code on the user's machine.

Tracking, terrible website accessibility, and various dark patterns are a direct result of this. Instead of forcing websites to conform to a document format and giving users control over how that document behaves and is rendered, browsers given those powers to websites, and unsurprisingly, this has resulted in user-hostile behaviors. And it's not all peachy for websites either: websites can do a lot more with CSS/JS, but websites also have to do a lot more.

One of my side projects is a web browser which accepts various document types (i.e. image, slide show, article, login form) and renders them. Style/behavior is configurable by the user when possible, but the site serving the document has no control over styling/behavior--they only get to serve up documents which conform to the semantics of the document type. I doubt this will ever take off, but it's been an interesting and fun project so far.

That's a nice way of breaking down the various designs one has to support, 48 is actually quite a lot.

Some teams will start with 'visual' design at the beginning of the process and, in that case, will do the ~48 mockups before any code is written (it's more because there aren't just 2 different screen sizes). It's a more satisfying (and perhaps cheaper) process to develop in stages:

- content hierarchy (what's important on one platform will rarely change between other platforms, despite the developer guessing otherwise)

- interactivity (the platform can most of the time cater to the differences in input if you lean on the platform capabilities)

- style

- Iterate and Perfect on the 48 versions

That's 48 combinations to design and test for.

And then imagine if your web site is multilingual...

You don't have to do any of those things. In fact the a good strategy is to use as little CSS and JS as possible and things will mostly just work, now and in the future, for all users.

No need for dark mode if the canonical design is dark. I wish this was more prevalent.

Shouldn’t the color scheme be orthogonal to input methods, platforms, and device sizes? I can’t think of any times I have changed colors specifically for any of those things.

I can design the same dark color scheme for iOS and Android, but I've still got to code it twice.

Or use the same dark colors for mobile-size and desktop-size in responsive, but still need to test it to make sure I got all the <div>s that appear in mobile-size but get hidden and/or replaced by other <div>s in desktop-size and vice-versa.

Or discover we thought we'd covered everything, but when you use the normally-touch interface with a trackpad on Chromebooks, the default hover state is still light-mode.

Etc.

The trick is to make the base as simple as possible. A static page, no items hidden behind mouse clicks or hovers. Good contrast between text and background, make sure text is resize-able. No fancy div's or nested table's for layout - so the text can flow freely and adapt to any screen size.

Only problem - that is not what the market wants. Client: "why did you not implement the scrollbar-hijack/moving-blinking-text!?!?"

Is it even a website if the videos don't autoplay and follow you, there aren't at least two modals urging you to subscribe to a newsletter, and at least one Amazon referral link?

I don't think it's a problem; the Wordpress people fix it once in their most popular themes, which then immediately fixes it for 30% of the web.

The problem is that this doesn't let the user toggle dark mode on/off.

If you want the user to be able to toggle dark mode on your site without changing their Operating System preferences, then you'll need to implement your dark theme as a class (eg. body.theme-dark) since there's no way to dynamically set the media query.

  const darkMode = window.matchMedia('(prefers-color-scheme: dark)')
  if (darkMode) {
    document.body.classList.add('theme-dark')
  }

If you have to write your dark theme CSS as a separate class, then there's no sense in duplicating that logic inside the media query and having to override it when the user toggles it. So I ended up using that Javascript instead of putting the styles in the media query.

It's a shame, I would've preferred a pure HTML/CSS solution.

Is there anything which allows user choice (i.e. state) that doesn't involve JS?

You can use checkbox inputs (the reason why HTML&CSS is turing complete)

Yes, although doing things without JS is old school web. I think you'd be hard pressed to find any clients that don't support JS in this era.

Anyway, to accomplish this you would split your styles into seperate CSS files and then have a drop-down that does an HTTP POST/GET to a server side script that will then set a cookie on your browser with your preferred choice.

Each time a request comes in from the client you just check that cookie for which style they want and then change the HTML that's sent to include a different stylesheet.

There's a number of end users who would like to avoid JS on non-app sites.

Yes, you can use an html checkbox and monitor its state with pure css.

Checkbox + CSS custom properties for the colours/font weights etc . Checkbox checked, adjust the variable values.

There's normally a little more to it than that, but there shouldn't ever be _much_ more, custom properties are fully dynamic

There's also alternative style sheets (https://developer.mozilla.org/en-US/docs/Web/CSS/Alternative...), that can support the media queries on the tags, but I think Firefox is the only browser still exposing the ability to switch the styles, and it sadly don't persist between sessions or even a page navigation/refresh.

To me it seems like now that all browsers support the prefers-color-scheme media query, it’s no longer a best practice to allow/force users to toggle between light and dark theme separately from the OS. Centralization of config is a good thing, freeing people from rote work.

I strongly disagree. Users should be able to control their preferences by application, and not be locked into an OS setting.

My suggestion of still using classes doesn't eliminate centralization of config, it just means moving the dark mode CSS outside of the media query and into a class, and adding a couple lines of Javascript.

What I’m hearing is, “My precious snowflake app is so important, users must manage its appearance independently of the OS.” Once you allow the possibility of a different app setting, you effectively require them to continue managing it separately. You can’t respect both OS- and app-level settings, so you're going to ignore the OS.

If your app really just has light and dark theme choices, you should get rid of the toggle and move all your dark class styles into the prefers-color-scheme:dark media query instead.

Uh, no. What you're saying is "My user should not be allowed to customize the appearance of their application."

You want the user to have less freedom? Great, good luck with your app development, but I sure hope you're not in charge of developing anything I use.

Also if you read my original comment you would've seen that I am still reading the OS setting. The difference is that rather than locking the user into their OS's setting, I default to the OS's setting and give the user the freedom to change it as they see fit.

How is that going to work? User arrives at site, OS is set to dark, site is toggled to dark, so far, so good (assuming the toggle is smart enough to be set appropriately at this point).

1) User toggles OS to light, is your site going to switch back?

2) User toggles site to light, and back to dark to see what that does, now there's a persisted app setting. User later realizes they don’t like dark, toggles OS to light, and then has to think about your app's unique way of toggling it back.

To me, that's just unwieldy for very little gain. Why would I want your app to be inconsistent with everything else, other than a poorly executed dark mode?

While there’s a good chance you won't be using my current apps, I’m confident I won’t be the only one to reach a similar conclusion, so you'll likely have to get used to the behavior.

Your name here seems quite appropriate, as that was a weasel tactic, rephrasing the opponent's words to modify their intent. Not to mention you also used a quite inflammatory tone towards someone who's strongest words were "I strongly disagree".

I never saw any assertion that the user must manage apps individually, only that they should be able to. Easy way to do that - by default, the app echoes the system setting. If and only if the user manually changes the setting, does it diverge from that. Somewhat simple way around having a persistent setting get stuck - if the user switches back from the opposite mode, then you go back into "system" mode. So really, instead of needing two toggles, you would have one that has two states - "Respect system setting" and "Use the opposite mode from the system" (which probably need to be worded way better). The only snafu there that I can think of, off the top of my head, would be that if the user changes the system setting, the app state would likewise change.

It's also completely valid if someone doesn't wish to use system-wide dark mode (say, due to specific applications they use that may not function or render correctly in dark mode) but yet wishes to have specific apps in dark mode. I run Windows, which does have a dark mode nowadays, but that only works for certain apps that specifically use it (Windows Explorer does, not that I use that, along with many of the "modern" style apps that ship with Windows), and yet in apps like Discord I still prefer to use the dark mode, and I also have a dark mode extension for my browser.

For what it's worth, the site did correctly detect my dark mode setting in Windows, and display the dark style. As well, I don't necessarily disagree with any developer that does wish to exclusively use the system setting. However, I do see room for both approaches.

After some more thought, I’ve realized that should you want to allow but never force a user to manage appearance separately, you could give the toggle three options, ‘System setting’ (default), ‘Light’, ‘Dark’.

I don't particularly care for dark mode in web pages, however iOS apps which allow theming should allow the themes to be set independently of iOS.

For instance, the first version of Tweetbot for iOS 13 wouldn't allow you to choose a dark theme if iOS was set to use a light theme.

This was quite frustrating because I like Safari in light mode, but I like Tweetbot, iBooks, Kindle, etc in dark mode. This always has always worked and I'd see a different behaviour as a regression. That said Tweetbot fixed the issue very quickly (in a day).

Why do you like Safari in light mode, or dislike it in dark mode? Are you referring mostly to the app chrome or to the content of the sites you visit?

I would tend towards ease of configuration and consistency, and would only make exceptions for apps/sites with more theme choices than just light/dark.

I suspect it's because the light Chrome looks better to me with most web pages.

Whereas for apps with lots of text (e.g. Kindle etc) dark mode looks better (to me).

I think if most of the pages were also dark like the surrounding chrome, because they implemented a dark theme with the prefers-color-scheme media query, that we would find the experience more agreeable. We’re in the early days, but once the dust settles and most sites have implemented dark mode, I’d expect the dark web browsing experience to improve.

We have a design system that supports both black text on white and white text on black (as a contrasting block of content).

If we want to support dark mode now we have to support four different options. Writing that with a combination of classes and media queries is going to be a nightmare:

   .default-theme h2 { background: white; color: black }
   .inverted-theme h2 { background: black; color: white }

   @media (prefers-color-scheme: dark) {
     .default-theme h2 { background: black; color: white }
     .inverted-theme h2 { background: white; color: black }
   }

Your trick might make this a little more palatable.

[deleted]

Sorry, I missed the "without changing their Operating System preferences". I agree with another sibling comment here: that seems like bad practice.

EDIT: Just wrote a quick article elaborating/demoing what I'm talking about: https://www.jbernier.com/dark-mode/

Also I made a small mistake in the code there, it's `isDarkMode = window.matchMedia('(prefers-color-scheme: dark)').matches`

> Photographs also looked harsh. It turns out that many people prefer images, too, to be desaturated in dark mode

This is an interesting choice. While it might be easier on the eyes, personally it feels kind of icky to change colors on images…

Some global CSS themes change them, but then restore original ones on hover. Not perfect, but generally fine.

Though regular photos (and videos) are rarely so bright that it hurts the eyes while in a dark environment, unlike diagrams and other kinds of drawings, which can easily be mostly white.

Yeah that seems bad. If you choose low contrast fonts, reduce the contrast of photographs to the background by making them darker, etc, it's just like turning down the brightness and contrast of your whole site. If the user thinks the content of your site is still too bright with dark mode on, maybe they should turn down the brightness of their device?

By making everything on your site dark and low-contrast, the implication is that the user wants to see other things on the screen in higher contrast alongside your site, like the UI chrome. That seems unlikely - your site is the most important content that they have on the screen at that time and it should probably have the highest brightness or contrast of anything on the screen, not the lowest.

I prefer to hide all the images altogether.

I’m probably not representative of the general dark mode user, I think, but I enable dark mode because I want the UI chrome out of the way to concentrate on the content. I don’t want dark content. Is there a way to disable this media query?

In Firefox you can add "ui.systemUsesDarkTheme" as an integer in about:config and set it to "0" for forced light or "1" for forced dark. This setting changes what is reported by the media query, you can still set your OS and/or browser theme independently. You will need to restart Firefox to apply the setting.

If you just want chrome to be dark, you can install a dark theme such as: https://chrome.google.com/webstore/detail/just-black/aghfnjk...

I think you misread

> UI chrome

Versus

> Chrome UI

"UI chrome" refers to the browser UI itself -- everything that is not the web content. what are you referring to?

In the case of the Chrome web browser the Chrome UI is the UI Chrome though? What other UI elements are there not included in the dark theme?

Ditto. Duckduckgo seems to have added support, but has a preference to keep it light. I enabled light (despite system dark for reason above) but it means any new tab search flashes dark for a fraction of a second, before it reads the lightness preference cookie or whatever.

Annoyingly, DuckDuckGo doesn't let me set an adaptive theme if I change the font settings, plus they don't have an easy way to contact them either…

I did this recently for my new personal website! It's quite easy and really satisfying. I love doing as much as possible in stateless CSS instead of JavaScript.

http://www.brandonsmith.ninja/

I've been using it for a few months on my personal site as well.

It defaults to the light version and then switches to the dark them on request.

This is so people who don't care or aren't good with computers get the light version and those that can set the system theme have the option of getting the dark version.

https://thomasryan.xyz/

FWIW, your Posts/Demo/Resume links are laid out a bit oddly on my iPad.

Thanks for pointing this out!

I borrowed a coworker's iPad at lunch and fixed this bug.

As best as I can tell Safari wasn't respecting the text-align: right; CSS rule. I've switched to a flexbox layout for those elements.

> people who don't care or aren't good with computers get the light version

Or more importantly, people whose browsers/OSes don't set that CSS flag

I also did this on my personal website. I was surprised how easy it was, and happy that it was built into CSS, requiring no JS (as you said).

Mine too! Finally put up a personal site last month after not touching any web projects for a long while. I've checked out of a lot of social media and wanted my own place to put stuff and to poke around with javascript and web graphics.

One of the upcoming posts is going to cover handling dark mode for <canvas> content. So far I've just used transparent backgrounds with no black or white drawing so that it's visible either way.

https://will.institute/

Not much on it yet, just been slowly working through the setup for doing a canvas with a responsive site.

Neat tidbit - the logo image is a single SVG in shades of dark gray, which doesn't work well on a dark background. You can apply image transformations in CSS under the dark mode media query to adapt things like this:

    img#wi-logo {
        filter: invert(100%) brightness(110%);
    }

This is the same tool that the linked post uses for desaturating images, but adding that invert is a useful tool for dark mode. Personally I wouldn't recommend general image desaturation, photos taking more focus against a dark background is a good look if you ask me. At least consider making it an opt-in setting instead of the default.

What I did for my SVGs was use CSS to actually change the internal fill/stroke colors directly. Unfortunately you can only do this if the SVG is inlined as markup (as opposed to shown in an <img> tag), but it's computationally much cheaper than using filters, because the latter operate on the image as a set of pixels rather than a set of shapes.

The logo design itself is really slick, though!

Ooh, that's an interesting idea that I hadn't considered! My page is pretty computationally lightweight to start with (no 3rd party javascript) but if I'm ever in the mood for some unnecessary optimization that sounds like a fun one to experiment with.

Trade-off is slightly more data to send with each page, since you have to inline the SVG rather than having it cached after the first load. But it's a whole 2kb and could probably be smaller if I wanted to look into SVG optimization.

I've had CSS filters alone cause noticeable lag on certain machines in the past; they can really pound the GPU. That was a few years ago though, and on a bigger image. Also, I think I was using a blur filter, which is much more intensive than a simple color filter. So probably still not worth worrying about :)

Same here: https://phili.pe/

I've used CSS variables though, which make it even simpler. E.g. I have `--page-background-color` and `--text-color-primary` that are set to a certain default value. In dark mode, these variables are set to other values, removing the need to redefine the actual selectors.

Me too! CSS variables rock.

Did this about six months ago over at my site. Was annoying to get it right but glad I did.

Some people find these kinds of sites pointless these days, but I enjoy keeping one even if I rarely update it anymore. Spirit of the web and all that.

https://rymc.io/

Nice site, it works well on mobile, which is a bit of a pleasant surprise when it happens from personal blogs etc.!

FWIW the Twitter feed from, I assume, people you follow is a little odd though - it's not immediately clear that it's not you, nor about the article being viewed, which it doesn't necessarily have anything to do with, and it includes replies to threads. At the time of writing the top one is recommended reading that's 'racist from the start'.

Yeah, it bleeds a bit too much on mobile - younger brother passed away recently and I shoved the site out the door before heading back home to be with him. Desktop view has it more marked as separate content - e.g, that tweet is actually a Retweet with a comment, which is kind of a pain in the ass to handle from Twitter's API. Should find time to clear it up a bit I guess.

Site works well on mobile because I cannot stand sites that don't load quick + layout well on mobile, and considering the general content I post, I'd expect the audience to have the (relatively) same pet peeve.

I open sourced the activity scraper as well, if anyone's interested: https://github.com/ryanmcgrath/activity-scraper

Looking at the feed you should see if it's possible to exclude any tweets that begin with "RT" (retweets) or the "@" (replies). This way only posts you write should show in the feed, would make it much cleaner as without the full conversation contexts those other messages make no sense.

The GitHub activity feed is pulling in every comment you make, see if you can filter that to only show pull requests you've created to showcase your work. Maybe also include commits to your own projects if the commit length is more than a certain number of characters to filter out the small updates.

Heh, I should be clear: I consider the aforementioned Tweet/RT issue a UI/UX thing, it's otherwise working as designed.

I'm perfectly happy showing my @replies, rando GitHub activity, etc. Nobody is actually reading that sidebar, short of a select few - I like having that junk indexed in search engines attributed to my own domain.

It's free real estate. :)

Indeed! Same feelings here. There's something about putting something out into the world that can be whatever you want it to be.

Irrelevant but I wanted to thank you for the Old Reddit extension for Safari. That makes Reddit somewhat bearable again, although it still seems to lag while it loads their stupid new UI before doing the redirect (not sure if there's any way to avoid that).

Glad it helps! I hate when extensions aren't ported to Safari, so I just decided I'd do it myself. shrug

Sadly Safari's API isn't that great compared to those found in Chrome/Firefox; there's no way to catch the url before the page actually loads. I inject some JS to catch and redirect as fast as possible, but sometimes you'll see a flash of the new Reddit experience. If a better API becomes available at some point I'd gladly swap it out. :)

I like that you're using CSS variables to achieve this. I had to look up support for this , and it seems fairly decent. https://caniuse.com/#feat=css-variables

Now if only Hacker News would implement it!

I currently use 'DARK READER' for hacker news and it works quite well using the 'Filter+' theme engine.

The problem with browser extensions is that they're a massive security risk.

On some sites I've used it to get a good baseline then export the CSS and modify it from there.

How do you get your browser to even load custom CSS without an extension?

Without an extension, I don’t know an easy way. You could just build your own extensions from scratch and load it there. I used it to style my own sites for dark mode.

In my browser, Preferences > Advanced > Style sheet.

I use the following: https://userstyles.org/styles/113994/hacker-news-dark

Works great.

I've put an updated version here. This updated version is an UserCSS, which means it can be automatically enabled/disabled based on system Dark Mode setting.

https://raw.githubusercontent.com/kristofferR/userstyles/mas...

Awesome, and I see you fixed the vote button colors.

@dang Do you think this is something that can be added.

PLEASE.

I wish Hacker News had better mobile CSS in general.

My wife would be very grateful as I read Hacker News in bed every night and it lights the whole room up with all its white pixels.

Have you tried inverting the colours?

That’s a good idea! On iOS I configured the Accessibility Shortcut to enable Smart Invert when I triple-click the home button, and it looks like it will work perfectly!

Install Stylus https://github.com/openstyles/stylus/ (and fall in love with it), then install a style (e.g. https://userstyles.org/styles/97106/ ) or write your own.

Save this as userscript, or convert to bookmarklet.

    document.body.style.filter = "invert(1)";
    document.body.style.backgroundColor = "#141414";

I use a fine tuned custom stylesheet with Stylus chrome extension.

That actually works amazingly well! Nice!

The two best Dark Mode extensions just implemented automatic Dark Mode support (so the web goes dark automatically when Dark Mode is enabled) :D

https://github.com/darkreader/darkreader

https://github.com/openstyles/stylus (not built into release yet)

I like DarkReader, but it's been a huge exercise in patience seeing Firefox and Chrome getting all the updates, while the paid Safari version languishes.

By the extension author's own admission [1], the majority of the revenue comes from the Safari extension, but he still prioritizes the (I imagine) larger user base of the firfox and chrome extensions. It's frustrating, to say the least.

[1] https://github.com/darkreader/darkreader/issues/1205#issueco...

I did this for the KDE wikis {userbase,techbase,community}.kde.org, this was a lot harder than I first thought, because of the amount of user contributed content with white background, hardcoded color in the text.

I wrote about it here: https://carlschwan.eu/2019/07/12/new-userbase.html

I baked dark mode into my css microframework [0], and it's always so satisfying to see people using it !

I didn't do the "dimmer images" thing, but I'll try it sometimes.

[0] https://concrete.style

That's a great micro framework

I apologize for my ignorance, but could somebody explain the need for dark mode? I know that it's bad to have a phone glow in your face when your eyes are adjusted to the dark, but don't most phones automatically lower the brightness? That seems to work well enough for me. Perhaps a specific dark mode could do it better, if well designed, but most sites have a hard enough time doing one good color scheme.

I know some people would prefer a light-on-dark color scheme in general, even during the day. Is this entirely about what you see in the dark, or is there a component of wanting more "skins" in general?

Aside from being able to use your phone at night without blinding your partner, another positive aspect of dark mode is the battery savings with OLED displays. Because the blacks on OLEDs are not emitting light, some simple text on a page saves a very surprising amount of battery.

There's a good discussion of "why dark mode" in the article that mine links to: https://web.dev/prefers-color-scheme#why-dark-mode

Thank you.

Here is another article that goes much deeper into how to actually use CSS to implement the dark mode. While it does not rely on the media query (the article is almost 17 months old after all), it shows many other CSS features you could use.

https://medium.com/@mwichary/dark-theme-in-a-day-3518dde2955...

If you want to make sure your website is pleasant for dark-browsers, check if it doesn't break with extensions such as https://addons.mozilla.org/en-US/firefox/addon/dark-backgrou...

The problem with all these dark modes is that I end up with 50 shades of grey and things are harder to distinguish because there's no consistency on where to apply the various shades.

It's a testament to how primitive the web is as a platform that it can't do something like apply a universal theme like Windows 3 did.

Sounds like good news, and similar to how Emacs handles it; do newer versions of web browsers also change the base/default colours when dark mode is used, by the way?

Still not a complete replacement of global colour overriding (white flashes, or simply switching between dark and light themes often, can be quite unpleasant in a dark environment, and of course all the websites won't ever employ it, and some will use it wrong), but at least from the webmaster side it should simplify the colour theme decisions quite a bit (which were/are hard if you care about that sort of thing: I hoped that major web browsers will do something like that with alternate stylesheets someday, but as a media feature it would work too).

> do newer versions of web browsers also change the base/default colours when dark mode is used, by the way?

iOS at least does not. Perhaps because some sites customize foreground colors but not background colors or vice versa, and they’d break if the foreground wasn’t dark or the background wasn’t light.

Try accomdating for Dark Mode as an email developer...

How would you do that?

No way as of yet. At the moment the best bet is to ensure that images accomodate for dark mode (particulary in email clients such as Outlook). Hopefully on the future this can be done with a line of CSS -_-

Have you seen this? https://sidemail.io/articles/dark-mode-in-html-email/

I recently added dark mode support with a new website for myself, using (prefers-color-scheme: dark) by default, but also allowing the user to switch between light and dark mode if they have JavaScript enabled. It also supports switching image sources in dark mode, so that I can use a dark mode screenshot in dark mode, and light in light. (I haven't yet published the draft article I have using this feature.)

I wrote about it at https://chrismorgan.info/blog/dark-theme-implementation/.

SteamDB also recently added this too, but it also doesn't require JavaScript, as it's based in the cookie. The toggle does use JavaScript if you do have it enabled

So that's why sites have been annoyingly turning dark lately. In Firefox apparently this can be disabled by creating a new integer preference in about:config called "ui.systemUsesDarkTheme" and setting it to 0.

I have chrome updates restricted by my organization and can't use this feature. Instead I'll occasionally use this bookmarklet to invert colors on very bright pages:

javascript:(function() { var tag = document.createElement('style'); tag.type = 'text/css'; document.getElementsByTagName('head')[0].appendChild(tag); tag[ (typeof document.body.style.WebkitAppearance=='string') ? 'innerText' : 'innerHTML'] = '* { background-color: white !important; color: #444 !important; } html { filter: invert(100%) grayscale(100%); }'; })();

> It's recommended to avoid pure white for text, and I chose likewise to avoid pure black for the background.

This is such nonsense. Pure black is never pure black on a monitor and neither is white. And the link he provides just restates the assertion with no additional reasoning.

See, I get it. If you create work as an artistic statement, you deliberately pick not-quite-blacks/whites because the defaults are not your artistic choices if you just default to them.

However, once you take this as a given rule and you pick some not-quite-white because "it is recommended", that defeats the entire purpose.

Does not seem to work in Firefox for Android.

Do you have Android's dark mode enabled, and is your Firefox up to date? It's a pretty new CSS feature

Doesn't work for me either. Android 10, Firefox 68.1.1 and Chrome 77.0, dark mode activated.

Weird. It's supposed to work on Android Firefox 68; Chrome 77 is unclear:

https://caniuse.com/#search=prefers-color-scheme

Works for me in Firefox Preview, there's an option in Settings > Theme.

Looking forward to this being implemented. Since my phone is my only OLED display, it's also the only screen where dark mode really makes a big difference in total light emitted.

How does one enable this setting in Firefox?

It's OS-level. macOS, iOS, Android, and I believe Windows 10 will all send this signal now to whichever (modern) browser you're using.

As will Linux/Gnome.

Any idea how to set this on Ubuntu? I have what I assume is the dark theme - title bars are white text on dark grey background - but this website displays a light theme in Firefox.

It depends on your Gtk theme, I think. If it's marked as dark, then Firefox will pick that up and apply the CSS accordingly. I use Yaru-dark.

You can also force Firefox, via an about:config setting to act as if you were using dark mode.

I think it's an OS setting rather than a browser setting. On Windows 10 I just searched 'Dark Mode' and toggled 'Default app mode light / dark'

browser.in-content.dark-mode

Seems it happens automatically if you use the default theme

Set ui.systemUsesDarkTheme = 1 on about:config

It's not widely available yet, https://caniuse.com/#search=prefers-color-scheme

True, but does it have to be?

The beauty of this setting is that it falls back 100% gracefully. Basically if your OS and/or browser doesn't support it, then you just see the "normal" version of the site.

Because Dark Mode is only available on newest versions of most operating systems, it is also reasonable to assume that the people running a dark mode compatible device would have a modern browser.

So all-in-all, I think compatibility is a moot issue.

Slightly off topic,

I find it kind of ironic that there's so much debate surrounding the intricacies of dark mode support on a forum with no dark mode support (even though it avoids 90% of the gotchas).

Shameless plug: I did the same thing to my personal website and wrote about it with light/dark screenshots: https://www.reillywood.com/blog/dark-mode/

I like working in Solarized Dark, so I wanted my website to serve up Solarized Dark. I dim images in dark mode too, but I turn them up to full brightness on hover.

I only use Solarized for code snippets on my website, but the benefit of using it as a color scheme is that switching between the two is a one line addition: only the background needs to respond to prefers-color-scheme.

Yeah, that would be nice for UIs that can use Solarized Light. I experimented with it as a full UI, but it just didn't look quite right to me – I ended up only using it for light mode code snippets.

One of my (maybe unwarranted) concern with automatic dark mode, is the potential ability of the browser and apps to determine my (very) coarse location based on when the dark mode is enabled or not, as it because another potentially identifying info among others.

Does that kind of CSS allows a script to determine if the browser is displaying dark mode or not, or send back that information to ads servers?

Yes, you could craft CSS to conditionally load an image based on the media query. This would let a server observe the client's setting.

Naïvely I tried to do this by overriding a few custom properties and using filters. My site has a position: sticky nav, and filters introduce a stacking context, so things which filters apply to naturally go on top of the nav when before they went behind. A minor annoyance, but it demonstrates how introducing a dark mode isn’t as straight forward as I thought it would be.

I wish more stuff was presented also as a header, so you could serve a specific CSS file for people who prefer dark-mode.

Where did this dark mode craze come from?

Don't get me wrong - I quite enjoy dark mode most of the time, but why now and not earlier?

To speculate, screens are progressing to display dark mode well. I get eye strain from Jetbrains Pycharm dark theme, the terrible way it renders on my laptop, so I am holding out now. Holo theme for Android may have accelerated the trend from 2012.

https://android-developers.googleblog.com/2012/01/holo-every...

I feel like it leaked from developer software engineering culture into the mainstream. Dark mode on text editors has been a thing for a long time,

I’m guessing a few people finally decided to do it in other places.

Doesn’t work in Chrome on iOS 13.1.2 for me. Works in Safari though.

Not working on Firefox for iOS. Can anyone else confirm this to be the case? Looks as though Firefox for iOS does support ‘prefers-color-scheme’ media query.

I'm quite surprised, as Firefox on iOS should be using WebKit…has Firefox linked against the iOS 13 SDK yet?

I can confirm that dark mode does not work on iOS Firefox.

I tested it a month ago and figured an update was coming soon. But I just tested it again on iOS 13.1 with everything up to date and still no luck. Safari works as my control.

I get that you want to avoid pure white, but why avoid pure black though? It looks gorgeous on an OLED device, blending with the bezels.

I would really love a dark mode for hacker news!

Can HN implement this one day? A dark mode for this website would be great.

Please add IE6 support

Wikipedia needs this.

yes yes there's browser plugins, but I'd rather not have some rando plugin potentially reading every site I visit to load a dark mode plugin on the ones it recognizes.

You can try https://en.wikipedia.org/wiki/User:Volker_E._(WMF)/dark-mode for now. It's a black/night mode at the moment. And (not yet) an official option with some technical acceptance issues like lazy-loading, therefore flicker on load. – I work for the Wikimedia Foundation. This wish has been stated as part of the Community Wishlist survey 2019. https://meta.wikimedia.org/wiki/Community_Wishlist_Survey_20...

Reply on news.ycombinator.com