Add light/dark mode preference

[elevenchars]

Problem

Browsers do not let you set a per-site dark mode preference. Some users do not want to use the new dark mode.

Description

A toggle similar to the Wikipedia appearance (see below). It should probably be accessible for users who are not logged in, as well.

Screenshots

[DaveF63]

The tile screen didn't need dimming; it makes it difficult to read.

[TurnrDev]

I agree, there needs to be a config option.

[mxdanger]

There should be absolutely no image or map dimming. It just reduces readability.

Just leaving this comment here so an option is NOT created for it. The dimming shouldn’t be a thing.

[nickvet419]

It darkens the map background, which also dims the map. and no option to disable dark mode on the page.

[kartomonkey]

Having a dark menu bar is nice, but simply dimming the map is just not acceptable. Maybe as a first step towards a truly dark mode, but please, please, please make it easy for the user to switch back to light mode.
The toggle is a must!

[tonytechhelp]

We need this option, until the dark mode improves, otherwise the visibility of the map and its use is reduced.

[gravitystorm]

Please keep discussions here related to having an option to enable or disable dark mode. The exact implementation of dark mode for the maps is off-topic for this issue.

[hlfan]

related to having an option to enable or disable dark mode

Just one option? Why not more?

[pnorman]

Some users do not want to use the new dark mode

This would only apply to users who want to use dark mode in general, but not on OSM. Is this a large body of users? Could it be reduced with improvements to dark mode?

[TurnrDev]

Could it be reduced with improvements to dark mode?

For myself, I value the ability to turn off dark mode for individual sites entirely. When working on maps, I often cross reference images, notes and other information, most of which don't have a "dark mode" so the switching back and forth is jarring.

[pnorman]

For myself, I value the ability to turn off dark mode for individual sites entirely. When working on maps, I often cross reference images, notes and other information, most of which don't have a "dark mode" so the switching back and forth is jarring

I would have thought this would result in you turning off dark mode in general. What I'm interested in is why you want dark mode for everything else, but not for OSM.

[Nekzuris]

why you want dark mode for everything else, but not for OSM.

Not only OSM, but maps in general looks bad in dark mode. I have all my apps in dark mode except maps app.
But a darker UI with normal tiles looks nice.

[DaveF63]

What I'm interested in is why you want dark mode for everything else, but not for OSM.

Because it dims the graphic screen!
@gravitystorm is incorrect to perceive "dark mode for the maps is off-topic"
They are determinately intertwined.

I think the obvious needs pointing out - this is on the front of house screen. it's the first thing newcomers see, and when I say "see" I really mean they can't see because it's too dark!

I've thought about this since it's implementation & I'm struggling to comprehend how everybody involved in alpha & beta testing looked at the webpage in front of them & thought, 'yeah, that's a great way to promote OSM to the masses.'

[CrabstickOMalley]

Having a dark menu bar is nice, but simply dimming the map is just not acceptable. Maybe as a first step towards a truly dark mode, but please, please, please make it easy for the user to switch back to light mode. The toggle is a must!

THIS EXACTLY. The menu dark is fine but the map itself should have a control or option or no dimming at all. I'd be happy to have all the rest of the hipsterprogrammerforcedoneverybody Dark Mode but don't DIM THE MAP!?!??

[CrabstickOMalley]

Because it dims the graphic screen! @gravitystorm is incorrect to perceive "dark mode for the maps is off-topic" They are determinately intertwined.

Exactly. That user has declared multiple interrelated microissues with strict "off topic" rules for each which is illogical and impractical. A "non-map-dimming dark mode issues" topic is reasonable but splitting up "how to dim maps when they are dimmed" and "UI for preferences/dimming control" and "whether or not to dim by default" etc. etc. into mini-issues while forbidding mention of any of the other considerations prevents normal and natural discussion of the best holistic solution. Which obviously is to create an easy and obvious user preference/dimming control of some sort instead of ivory tower deciding users should use what programmers think is best for them even if they hate it. Which is where we have ended up with the current lousy situation forced upon us.

[gravitystorm]

@gravitystorm is incorrect to perceive "dark mode for the maps is off-topic"

I want to clarify here that I didn't say that, I said "The exact implementation of dark mode for the maps is off-topic for this issue." What I mean is that it's not the right issue for discussing things like whether brightness(0.8) should be added before or after rotate(180) or which option from #5328 you prefer.

There's a lot of people want to discuss a lot of different aspects of dark mode (like 100 comments per day) so it's important that we don't mix every topic together otherwise nothing actionable will come of it. I know a lot of people don't like this, and would prefer a general discussion about everything all at once, but one of my roles as maintainer is to keep discussions on track towards things being decided and code being written.

[gravitystorm]

As for preferences, I'd like to hear from people what kind of preferences they would like to see. So far, across multiple different threads, I've seen the following:

• Automatic / Light (always) / Dark (always)
• Should this be stored per-user or per-browser (e.g. someone wants dark-always on their laptop but automatic on their phone)
• Should the map be controlled separately from the rest of the site UI
• Should each layer of the map be controlled separately (e.g. show dark mode for one layer but light mode for another)

[pkrasicki]

Here's a simple UI proposal:

Dark theme toggle depends on system settings (just like now), but user can override it by pressing the toggle button in top left corner. The setting will be remembered in local storage. The map theme is set to Auto by default, which means it follows website's theme. But users can override that by selecting Light or Dark (it's for the whole map, it's not per layer).

[hlfan]

Adding onto @pkrasicki's proposal:
Modern CSS could even skip the body class:

.leaflet-tile-pane .leaflet-layer:not(.dark), .mapkey-table-entry td:first-child > * {
	body:has(input[type="radio"][name="filter"][value="light"]:checked) & {
		filter: none;
	}
	body:has(input[type="radio"][name="filter"][value="dim"]:checked) & {
		filter: brightness(80%);
	}
	body:has(input[type="radio"][name="filter"][value="dark"]:checked) & {
		filter: invert(95%)hue-rotate(180deg);
	}
}

And yes, this shouldn't be implemented like this, but I like the idea of the simplicity in this.

Notably, this would also ensure usability for non-logged-in users.

[hlfan]

If that setting is stored in a cookie instead of in localStorage the server can already set the theme to avoid flashbanging users reloading the site (e.g. to see how their edits show up), as this would probably come rather late in the packaged js.

[omcnoe]

The solution to dark mode for the tiles isn't to dim the light mode tiles.

It's to design and develop a dark version of the standard tile theme. This is approach taken by Google Maps and Apple Maps.

[hlfan]

However, for OSM's most prominent raster map, Carto, this isn't planned, as it's considered out of scope. gravitystorm/openstreetmap-carto#5044 (comment)

[AndrewKvalheim]

It’s unfortunate that a website has to consider implementing this at all. Ideally it could just respect prefers-color-scheme and let the browser handle asking/remembering your preference.

[gravitystorm]

Thanks for your comments. Here is my proposal.

(You can think of this as a hierarchy, where each line is an override for the previous step)

1. We should continue to serve light mode by default.
2. If a browser requests dark mode (through the prefers-color-scheme mechanism) then we should continue to do that.
3. (If browsers start implementing native support for per-site choices then great, that would work too. But it's not available yet for most browsers.)
4. We should add a color-mode preference for the overall UI. It will have three choices: Auto (default) / Light / Dark. This can be used to override the mode that their browser has asked for (i.e. it's useful if your browser asks for dark but you want to see light mode, or vice-versa).
5. We should add a color-mode preference for the maps. It will have three choices: Auto (default) / Light / Dark. By default, the maps will be the same as the UI, based on all the above steps. This preference can be used to override the color-mode just for the maps, so you could e.g. see light mode maps in a dark mode UI, or dark mode maps when using the light mode UI.

Here's some worked examples:

• prefers-color-scheme = dark, UI mode preference = auto, map preference = light: Dark UI with Light Maps
• prefers-color-scheme = not set, UI mode preference = light, map preference = light: Light UI with Light Maps
• prefers-color-scheme = not set, UI mode preference = auto, map preference = auto: Light UI with Light Maps
• prefers-color-scheme = dark, UI mode preference = light, map preference = dark: Light UI with Dark Maps

I hope this is clear and logical. This will allow a reasonable amount of control of how the site looks, respecting the browser settings by default but allowing people to override it if they want to.

At this stage, I'm not proposing preferences for the following:

• Per-style preferences. That would allow you to e.g. have dark mode for all maps, except one particular map, which you always want to see in light mode (or vice-versa).
• Global (or Per-style) personal map filter preferences. That would allow you to "pick you own filter" to override the cartography.

The reason that I'm not proposing these preferences right now, is that I'm not sure they are necessary, and I want to make progress and I hope that a more simplified system can be finished and tried out more quickly.

At this stage, I'm also proposing:

• Preferences should be based on your user account.

This matches how github has implemented their preferences, and how we currently handle language preferences. So for example, your preferences would apply to all your own browers/devices, and will only take affect when logged in. Again, this is because I want to simplify the implementation and get it working more quickly.

Now straight away I know that not everyone will be happy with this, and some people will want more preferences or have some use-case where they want dark mode on their phone and light mode on their desktop despite their browser settings or something similar. What I would like is for people to think whether my suggestion is a step in the right direction, and if we can get a rough consensus on that to get started.

[AntonKhorev]

@gravitystorm Is 5 "let's make everyone use this particular filter in dark mode" (which filter?) or is it "let's make everyone have no filter until the cartographers let them have some filter"?

[gravitystorm]

"let's make everyone have no filter until the cartographers let them have some filter"?

Technically that depends on the discussion in #5328. It doesn't strictly matter how dark mode maps are implemented, in order to have this preference available and useful.

But yes, since my preference is for cartographers to choose what each "light mode map" and "dark mode map" looks like, then if you choose the "map preference = dark", then you would see whatever the cartographers have chosen - whether that's implemented by filters or alternative tile urls or the same cartography for each mode.

[hlfan]

Should cartographers have the choice to use a specific style and a filter or is it an exclusive or? Because this would change how I would implement this choice.

[gravitystorm]

Should cartographers have the choice to use a specific style and a filter or is it an exclusive or? Because this would change how I would implement this choice.

I'm sorry, I don't understand your question.

[hlfan]

If a hillshaded map is featured in light mode, and the cartographers' decision for the dark mode variant is to have a light version of the style without hillshading be inverted by the browser.
This would mean a different URL/style and a filter. Should this be permitted?

[gmar5]

Personally, I find the discussion of "colour-modes" for maps misleading. Maps have colours, selected by the developers of a map style based on their own criteria and preferences. If you change those colours (you want them darker? a different background? inverted? etc.) then you are creating a new map style — a completely new one, or a variation of an existing one, it doesn't matter, they are distinct.
As a new map style, its most appropriate place in the website settings is the Map Layers selector, which is already implemented and working. No need of anything else.

Openstreetmap-carto, with darkened tiles, for me, is a new style. It can be implemented as such. It should never replace carto as the default on the website.

Filters which act on top of a map style are going against the desired outcomes that the makers of the style are seeking. I am personally against that idea.
If you want to introduce them anyway, then they should be controlled by optional settings. There should be no "auto" feature. The default, regardless of browser settings, should always be "No filter". And remember that most people will use the website without a registered/logged-in user.

Honestly, I don't think many people desire a filter, so I wouldn't waste time on it, but maybe it's just me.
Similarly, the UI is so minimal that a setting controlling light/dark would be nice, but not crucial.
I feel we are wasting time on hypothetical thinking and niche user cases, while ignoring the main desired feature: restoration of the default carto style (or any other alternative pick), as intended by its makers, for all users.

[hlfan]

Given the merge of #5362, should this issue be closed?

[Nekzuris]

No because non-logged in users can't edit it.

[TurnrDev]

I have to agree with @Nekzuris - accessibility should be available for all users, not just registered users. Should the preference be stored as a browser cookie?

[Nekzuris]

Apparently this was decided here but I don't understand this choice @gravitystorm.
Even for registered users it's bad because they can't set dark on desktop and light on mobile for example.

It also requires at least 6 clicks to change one value from the home page, 8 for both, +1 to go back to the home page.
This proposal is much better, and if you want Auto you can add a drop down like on https://developer.mozilla.org.

[AntonKhorev]

This proposal is much better

Only if you look at it in isolation, because there's also #5201 and you can't have a button in the header for every possible setting.

[AntonKhorev]

It also requires at least 6 clicks to change one value from the home page, 8 for both, +1 to go back to the home page.

3 clicks on Wikipedia in a similar scenario, without the Appearance sidebar visible.

You can propose:

• one always visible preferences button (takes space of one button, saves one click on opening the user menu dropdown)
• clicking Preferences going right to the Edit page (saves one click)
• clicking Update going back to referrer (saves +1 to go back)
• using radio buttons for preferences (saves one click per setting, makes the page larger but maybe you can argue doing this only for the most important settings)

[Nekzuris]

you can't have a button in the header for every possible setting

Sure, but I think appearance and language are important enough to be quickly accessible at all times, like on Wikipedia.

Another option to consider would be placing them directly in the drop-down menu, like on YouTube or Reddit:

[AntonKhorev]

Sure, but I think appearance and language are important enough to be quickly accessible at all times, like on Wikipedia.

UI language is not quickly accessible on Wikipedia: