Support dark mode #1888

It makes more sense to put them all in the same location. Signed-off-by: Johannes Schindelin <[email protected]>

The 'layout.scss' file is meant to be included only from the top-level `application.scss` file; It does not contain fancy reusable things like variables or mixins. Signed-off-by: Johannes Schindelin <[email protected]>

They have not been used since 92a2ad8 (Kill compass, 2015-03-24). Besides, their names are slightly misleading, suggesting that they refer to a color, when they actually have Boolean values. Removing them will make the next step easier, where we want to bulk convert the actual `*-color` variables from SCSS to CSS custom properties. Signed-off-by: Johannes Schindelin <[email protected]>

CSS custom properties are wildly popular, and have been supported by every major browser (except Internet Explorer, but you're not supposed to use it anymore, even Microsoft says so in https://blogs.windows.com/windowsexperience/2021/05/19/the-future-of-internet-explorer-on-windows-10-is-in-microsoft-edge/ because Internet Explorer has been unsupported since June 15, 2022). There is a slight complication here, though: We use the `darken()` and `lighten()` functions extensively, and they are SASS preprocessor functions, i.e. they are evaluated at compile time, while the actual CSS custom properties are evaluated in the browser. Therefore, we need to move every `darken()`/`lighten()` call into an individual CSS custom property that is evaluated at compile time. This is the first step in preparation for supporting dark mode on https://git-scm.com/. Signed-off-by: Johannes Schindelin <[email protected]>

Many operating systems let users choose between light and dark themes directly in the system settings. Web browsers can react to that via a @media query, which we do here. This commit draws heavily on the excellent guidance provided in https://css-tricks.com/a-complete-guide-to-dark-mode-on-the-web/ as well as on SASS' `@mixin` feature (for more details, see https://sass-lang.com/documentation/at-rules/mixin/). Signed-off-by: Johannes Schindelin <[email protected]>

In the preceding commit, I added support for a dark mode, heeding the operating system's indicated preference. However, many users will want to be able to switch from/to dark/light mode without switching the rest of their operating system. Guided by the excellent advice provided in https://css-tricks.com/a-complete-guide-to-dark-mode-on-the-web/ and in https://dev.to/ayc0/light-dark-mode-avoid-flickering-on-reload-1567, this commit introduces a button to toggle dark/light mode. To avoid flickering, the idea is to: - store the user preference in the local storage, - using Javascript, in the `<head>` section of the HTML page (so that it is executed _before_ anything is displayed), heed that stored user preference (if any) by setting the `theme` attribute in the `document`'s `dataset`, and finally - use that `theme` via CSS: :root[data-theme="dark"] { ... } Signed-off-by: Johannes Schindelin <[email protected]>

In dark mode, we do not actually want the textured background. Also, the sidebar needs to be adjusted, it had a hard-coded, very bright background. Signed-off-by: Johannes Schindelin <[email protected]>

As per the guidance provided in https://css-tricks.com/a-complete-guide-to-dark-mode-on-the-web/#aa-dark-mode-images wht this commit we tone down the images in dark mode, applying techniques to filter background images as described in https://css-tricks.com/apply-a-filter-to-a-background-image/. Signed-off-by: Johannes Schindelin <[email protected]>

WCAG 2 AA (the standard for accessible websites) recommends a minimum color contrast of 3:1 for links, if color is the only discerning visual marker. In dark mode, that would be a bit too bright, so let's add a wavy underline instead of increasing the color contrast of the links. Signed-off-by: Johannes Schindelin <[email protected]>

The verse blocks of the manual pages are unlike any other visual element, and therefore need special care to look good in dark mode. Signed-off-by: Johannes Schindelin <[email protected]>

This is a step in the right direction, there is one more instance of `#fff` (active drop-down titles) but it will be handled differently because `--main-bg` would be too dark. Signed-off-by: Johannes Schindelin <[email protected]>

The front page is the first page users see, therefore we need to make sure that it looks good in dark mode. Signed-off-by: Johannes Schindelin <[email protected]>

The links in the navigation bar are supposed to be colored dark gray unless the current page is in the corresponding section. In dark mode, however, it must be a bit lighter than the very dark background. So let's stop hard-coding that color and override it accordingly in dark mode with a nice, pleasant light gray. Signed-off-by: Johannes Schindelin <[email protected]>

The color contrast was not large enough; Let's just use a different variable to define the color. In light mode, it is similar enough: previously it was #4e443c, now it is #403f3c instead, i.e. a _tad_ darker. But it looks nice. Signed-off-by: Johannes Schindelin <[email protected]>

This includes the search box as well as the search results page. Signed-off-by: Johannes Schindelin <[email protected]>

It would stick out too much in dark mode otherwise. Signed-off-by: Johannes Schindelin <[email protected]>

The light mode colors in the versions and the translation drop-down boxes are waaaay to bright in dark mode. Signed-off-by: Johannes Schindelin <[email protected]>

Signed-off-by: Johannes Schindelin <[email protected]>

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Support dark mode #1888

Support dark mode #1888

Commits on Oct 20, 2024

Support dark mode #1888

Are you sure you want to change the base?

Support dark mode #1888

Commits on Oct 20, 2024