Dark Mode for maps

[gravitystorm]

I want to have a focussed discussion on Dark Mode and how it applies to the map layers.

To be clear, any discussions of user preferences, toggles, dark mode for the rest of the UI, etc, are off-topic for this thread.

As far as I see it, there are (at least) 4 options for the maps, and with the feedback received so far we have people voicing preference for all of them. Each of the options has both pros and cons so there cannot be a single right answer that will please everyone.

Option 1 - Unaltered Maps

For this option we show the maps in their original colour scheme. No filters are applied and the maps look identical in both light mode and dark mode.

Pros:

• The cartography is exactly what you expect and are familiar with
• Some people use dark mode for higher contrast when reading and don't want colours or brightness of maps changed
• Cartographers are in full control of the maps

Cons:

• The maps are all have bright, near-white backgrounds, but many people use dark mode because they want less light output overall
• Can be quite jarring between the UI and the maps

Option 2 - Darken the maps

A simple filter makes all the maps darker, but without changing the colour hues or inverting the brightness or other changes

Pros:

• A simple filter is reasonable performance on all devices
• The overall light output is lowered, leading to a dark effect
• There's no substantial changes to colour interpretation

Cons:

• Reduced contrast makes the maps more difficult to read
• The colours are still different from when the maps are used elsewhere
• Removes all control from cartographers

Option 2b - more filters

Another filter can be added to improve contrast

Option 3 - Colour inversions

More complex filters to invert the brightness of the maps, so that light areas are dark, and dark areas are light. Typically by using a combination of invert and rotate so the colour hues are restored after the inversion.

Pros:

• Closest to what we've done for colours used on other parts of the UI

Cons:

• Multiple filters have performance impacts for slower devices
• Colour manipulation is not done in a perceptual colour space (for example, light yellow to white is easily distinguishable, but the same difference in RGB values between extremely dark yellow and black are not distinguishable). This can lead to perceptual contrast problems.
• Can have unexpected effects for shadows (e.g. hillshading or building shadows)
• The colours are still different from when the maps are used elsewhere
• Removes all control from cartographers

Option 3b - Colour inversions with more filters

A variation on 3, but with additional contrast, brightness or other adjustments. This tends to be optimised for personal preference or tuned to one specific map layer, and has additional performance issues with the increased number of filters.

Option 4 - Full Dark Cartography

The cartographers have a completely separate map rendering for dark modes. They have full control over the colours chosen (and these don't need to be inversions, for example the Thunderforest Transport Dark style has yellow railways instead of the original black or the typical inversion of white).

Pros:

• Cartographers have full control
• Edge cases in contrast or visual perception can be fixed

Cons:

• Requires more work for every style shown
• Some organizations don't have the server capacity for a second map layer (e.g. those using mod_tile)

Option 4b Full Dark Cartography with fallbacks

Like Option 4, but for styles without a dark variation, we chose a fallback approach, which is then one of options 1,2, or 3.

---

So those are the options as I can see them. If you have another option that isn't mentioned above (n.b. no discussions of toggles or similar) then please comment below. If you have additional pros or cons, or have seen other pros and cons mentioned in other discussions, please comment below.

[gravitystorm]

Ha, it turns out I opened exactly the same issue six month ago, but with no substantial discussion since. See #4769 which I'll close because this one has more options.

[AntonKhorev]

@gravitystorm Do you plan to make your dark transport map available on the osm website?

[lenaschimmel]

Since all options have their pros and cons, ideally all of them wound be implemented, and which one is used should be user-selectable. I know that user options for dark mode are primarily discussed in #5324, but until now it's just about choosing if dark mode should be enabled, not about switching between different implementations. Here I see some overlap between both issues.

Regarding option 3b (advanced filters) I'd like to suggest this article as explanation on why this is important, but hard. The actual filter that is proposed there could also be a baseline for further optimization. It's kinda optimized for (Gooole) maps, so it might work for OSM as well.

[AntonKhorev]

Option 2 - Darken the maps
Cons:

Reduced contrast makes the maps more difficult to read

Option 2b: compensate for this by increasing contrast, see #5325 (comment)

The colours are still different from map keys

They aren't because the filter is applied to keys too.

Removes all control from cartographers

Certainly not "all", arguably even no control is removed compared to turning down the monitor brightness.

[gravitystorm]

@gravitystorm Do you plan to make your dark transport map available on the osm website?

Sure, I'm happy if we want to use that. I don't want to set accidentally set expectations for other projects though, since it's much easier for us to make and host alternative styles than it is for volunteer groups to do the same.

They aren't because the filter is applied to keys too.

Fair point, I'll remove that from the list. I was thinking of keys hosted externally (like on OpenCycleMap) but it's mostly applicable to keys hosted here.

ideally all of them wound be implemented,

I'm don't think that's feasible really. That would imply that every map layer is provided in two variations, plus also two different filter approaches, plus some way to choose between them all. I think that's unrealistic.

[AntonKhorev]

Inversion with hillshading doesn't look better to me. And half of our featured layers have hillshading.

https://www.openstreetmap.org/#map=10/46.1304/11.5926&layers=P

80% brightness:

invert+hue-rotate:

You can test different filters with #4777.

[gravitystorm]

Inversion with hillshading doesn't look better to me.

Yes, that looks terrible! I can try as hard as possible to trick my eyes, but it looks like the roads are running along mountain ridges.

[hlfan]

This boils down to two choices: CSS filters yes/no or custom dark mode tiles yes/no. If the filters would be loaded locally from user preference, and when the vector tiles arrive (that styling shouldn't come from CSS anyway), then the default should also be outside the main style file too.

But dark tiles aren't always worth the effort to implement. Tracestrack's dark tiles also invert the hillshading, so it looks like the light is coming from the south east. Thunderforest's transport dark features shadow-glows from buildings at higher zoom levels that seem also pretty unnatural to me. And "overriding" the hillshading with hillshade only tiles doesn't really work either.

[Nekzuris]

I see no one is testing for Firefox, option 1 should be used because CSS filter are not well optimized on Firefox and makes panning very laggy, even on good computer.

It's not very noticeable in this screen recording because you don't see the mouse input lag, try it for yourself.

map.lag.mp4

Edit: It doesn't affect everyone, I think it's hardware or driver related, see:
https://bugzilla.mozilla.org/show_bug.cgi?id=1826576 & https://bugzilla.mozilla.org/show_bug.cgi?id=925025
Edit 2: I resolved my issue here #5328 (comment)

[tomFlowee]

The idea of dark mode has always been about contrast. There is a substantial part of the population that dislikes the over-saturation of light as that makes the non-light elements get pushed out. Imagine ink on a napkin, it bleeds out and your text needs to be bigger and brighter to compensate.

So, for those people that dislike looking at bright sources, nightmode is a solution. Overall light output is less and that helps contrast of text and other details.

Unfortunately for this issue, there has yet to be a cartographer that actually sat down and made a dark-theme. The map theme isn't just about contrast, as inversion may solve, but the colors are actually really relevant for the recognition of elements. Imagine if we inverted the colors of a flag, not a good idea because the colors are quite relevant for recognition.
That red dotted line is a footpath, that blue one is a bicycle path. This is learned, this should be super consistent if changed.

Based on this thinking I would totally reject the darkening of tiles, it completely misses the point.

Additionally I would reject any auto-inversion of tile colors because that would utterly destroy the design. That green on the map is reconizable as forest and other things humans see as green. Water is blue. Train / tram lines are black. Houses brick-colored. Inversion just doesn't give you a good result if you just throw out the window all those intuitive and learned rules of what the colors are.

To be frank, other than a super simple map style that just shows roads and text, I've never in my life seen a good dark theme for maps.
I expect that it will take a lot of time to actually sit down and make one. And to be honest, with many places on OSM being mostly green or gray (residential) for background, I'd be surprised if it actually is needed at all.

To conclude;

1. Using dimming or auto-inversion is making things worse. Please don't.
2. A new theme may be designed that inverts some colors and not others to get the best result. But this is a manual effort that I'm personally not asking for.
3. The normal tiles (identical to the light theme) work and look good. As a long time dark theme user I'm not sure who asked for their colors to be fixed. Why fix something that isn't broken?

ps. libreoffice in dark mode still shows white paper and black text. Apps like inkscape and gimp obviously do too. If I go to Flickr com, all the photos are still showing me the original colors.
What is the rationale that OSM should include the tiles in dark mode? I don't think that is needed at all.

[Nekzuris]

The map is like a photo, and any photo-viewing applications display photos the same way regardless of whether they are in dark or light mode.

As previously said, dark mode is more about contrast, and should actually be bright if used in a bright environment.
If the user is in dark environment, he will dim the whole screen.

[AntonKhorev]

@tomFlowee You say this thing again

The idea of dark mode has always been about contrast.

and I did this exercise again, now with Wikipedia. Wikipedia has slightly lower contrast in dark mode.

[pkrasicki]

Of course dark mode isn't about contrast. It's about brightness. People either don't want to stare at a bright screen all day/night or they want to conserve battery on mobile. That's why we need a dark theme and a dark map and why other map applications have them. That's why option 1 is not a solution as it completely ignores the problem. No, this isn't an image viewer, we can display the information however we want.

When you're talking about inverting the colors, I hope you don't mean literally just that? We've already made at least 2 better proposals 3-4 years ago:
#2332 (comment)

#2332 (comment)

[Nekzuris]

These should be style on their own, but not imposed on dark mode users.
I think it's clear that many people appreciate the dark UI with normal tiles.

[pkrasicki]

So why have dark mode if the main element of the app isn't dark? If you want to have an option to configure this, I can understand that, it might be a good idea. But having a dark map in dark mode seems like a sane default for a map viewer application.

[CharliePlett]

First of all I would like to thank the developers for implementing dark mode after I requested it (I'm sure they were thinking of it before already), but I agree that the map should not be dimmed so much, as tomFlowee was saying here a few posts before.

[Nekzuris]

having a dark map in dark mode seems like a sane default

Yes indeed, but the current implementation by dimming 20% is worst than using regular tiles with a dark UI.
Dark mode should default to a proper dark rendering and still provide the option to use regular tiles without dimming.

[hlfan]

Couldn't the dark mode have waited for the release of the vector.osm.org tiles?
Then the light mode could've had the colorful style, the dark mode could've had the eclipse style (see tiles.versatiles.org), and that would have been the point of conversation instead of how dimming the map is seemingly the worst option.

[tomFlowee]

@AntonKhorev

The idea of dark mode has always been about contrast.

Wikipedia has slightly lower contrast in dark mode.

You didn't quote the full paragraph that tried to add the needed background. It factually is about contrast, but the simple comparing of two colors doesn't give you the contrast in a real world situation. Let me quote myself, but add emphasis:

The idea of dark mode has always been about contrast. There is a substantial part of the population that dislikes the over-saturation of light as that makes the non-light elements get pushed out. Imagine ink on a napkin, it bleeds out and your text needs to be bigger and brighter to compensate.

In a high-light environment (on a computer screen that emits light) the mathematically same contrast looks lower contrast due to eyes not being perfect or simply tired.
Have a low light environment (on light emitting devices) and the same contrast is better to read. So the GOAL is better contrast. And the wikipedia example that actually has mathematically lower contrast in dark mode shows the point I'm making that dark mode itself has such a high impact.

To use the opportunity: my preference is to keep the map tiles as is. As a long time dark-theme user I've never once had the wish to learn a new map legend, or have a problem with a mostly green and brown map being too bright.

[AntonKhorev]

@tomFlowee I'm talking about contrasts as reported by:

They don't change much between light/dark modes.

[AntonKhorev]

Do we need different filters for different layers? For example, we got here believers in inverse+rotate. Why do they think that it's the best option? Probably because it generally works for the standard layer. Even if you convince them that it doesn't work for all layers, they'll be able to say that most of people use mostly the standard layer, therefore it makes sense to pick the best filter for this case. This can be resolved by having per-layer filter settings. That also makes sense if one of the options is an alternative set of tiles, not every layer is going to have that.

Then the question is how do you present the options to the user. Because if we we put them to the user setting page, we'll need a table of layer x filter. That's probably not going to be very user-friendly. We can put the options in the layer selector like #5324 (comment), but that's more custom javascript than we'd have otherwise.

[Nekzuris]

They don't change much between light/dark modes.

They certainly don't decrease.

Do we need different filters for different layers?

I don't think filters are a good idea, we just need one good dark style. Styles have unique and carefully chosen color palettes, and you can't just apply a filter to make them dark mode. There will always be edge cases where it looks bad, as well as performance issues.

Couldn't the dark mode have waited for the release of the vector.osm.org tiles?

I think we would still be waiting for dark mode in 2030 if we waited for everything to be perfect. This will at least accelerate development. If a beta dark mode had been released in 2020, we would have a perfect one by now.

[AntonKhorev]

They certainly don't decrease.

Yes, I said that in case of Github they increase but not by much, in other cases they don't, so not "certainly"
#2332 (comment)

I don't think filters are a good idea, we just need one good dark style.

Do you mean not showing layers that don't have a version with dark tiles? Currently it's not an option because the standard layer doesn't have it.

[Nekzuris]

Do you mean not showing layers that don't have a version with dark tiles?

No, normal tiles with dark UI looks great, just add a dark style in addition to the others and make it default for dark mode but easy to change.

[hlfan]

Which dark style do you think of for this important default spot? Is it a dark carto or some other layer?

[Nekzuris]

That's the question, certainly not the current one with 20% dimming, maybe a more complex filter can work while waiting for vector tiles or simply keep the same as light mode for now.

[gravitystorm]

Thanks everyone for your detailed feedback.

As I mentioned on the forum I have a big conflict of interest here, since I'm both a maintainer of the site, but also a cartographer for some of the map layers. I need to be careful when making decisions which affect other map projects since that could be unfair to them.

However, as both a cartographer and a developer, it also means I have strong opinions on what we should do next!

I think the principle should be that the decision on what each map looks like in dark mode should be delegated to the cartographers for that map layer. If they want to make a separate map style, they can do that. If they want to apply a filter, we should offer them that functionality. If they want a specific combination of filters for their own layer, then that's their choice. Or if they want to stick with the exact same map in dark and light mode, then that's their choice too.

We don't control what colours are used on the maps in light mode, and so we shouldn't control those colours in dark mode either.

Call this "Option 4b", which would be:

"Like Option 4, but for map layers without a dark variation, the cartographers for that map layer chose a fallback approach, which is then one of options 1,2, or 3."

There are a few drawbacks with this approach. For example, the maintainers of the current default map layer (openstreetmap-carto) have stated that they aren't planning on creating a dark version of their style, and I doubt they will want to use any filters either. And I know that some people really don't want to see a bright map by default when they've asked for dark mode. But I think we have to accept that situation. Perhaps in future, when OWG are considering which maps to feature on the site, they will have some criteria around what the map will look like in dark mode. And maybe in the meantime, if many existing map layers gain dark versions (either through separate cartography or through filters) that will encourage other cartographers to consider the options for their own layer.

If we go with this approach (and let's face it, it's a big if, because I think a lot of people will also disagree with me here) then the next steps would be:

• Remove the site-wide filter that's currently applied to all map layers.
• Allow the cartographers for each map layer to either provide a second url, or a list of filters, to apply to their individual map layer in dark mode.

[matkoniecz]

sounds like a good idea to me

then the next steps would be:

I would suggest to also contact maintainers of featured map styles to let them know they have such choice and maybe list which ideas (dimming, various filters) can be used to autogenerate dark version, without developing new style on their own

even if some developers are not creating a dark version of their style due to effort required they still may have capacity to look at possible filters and decide to bless one of these

if there is interested dark mode fan, they may build a small site that can allow previewing transformations with already featured map styles (sounds like a small self-contained project) that may help map style developers to make a choice

[matkoniecz]

oh, and contacting above could be done not by maintainers of OSM website but by people interested in dark mode, just have some central location listing creating issues/contact attempts to not flood map maintainers

[AntonKhorev]

Let's suppose we have a group of people who don't want any filter and a group of people who want inverse.

I think the principle should be that the decision on what each map looks like in dark mode should be delegated to the cartographers for that map layer.

This proposes to let the cartographers decide which of the groups is wrong and will have to override the standard dark mode with browser extensions.

[Nekzuris]

In any case, the current implementation of the dimming filter for all dark mode users is problematic.

I believe that providing an easy way to switch between light and dark maps independent of the UI like this is essential, regardless of what we do for dark maps.

[gravitystorm]

Let's suppose we have a group of people who don't want any filter and a group of people who want inverse.

Yes unfortunately it's not possible to make everyone happy when their preferences are in conflict with each other. But we need to pick a default behaviour for when dark mode is active (see #5324 for more about when that might be).

If we implement my Option 4b proposal, and if we implement some straightforward preferences (e.g. auto/light/dark prefs for UI and/or maps) then I think most people will be reasonably happy with the outcome. We can then revisit whether people want even further micro-control like choosing their own filters (to override the decisions of the cartographers).

[pkrasicki]

It's also not helpful to dismiss other opinions with "people don't know how things work, so they're scared and afraid of change".
I explained some technical reasons why messing with the maps appearance means tampering with their message. It's measurable in numbers, don't dismiss it as uninformed fearmongering.

@Wilhem275 If your opinion isn't just based on fear, then you should have no problem pointing out what specific issues you've noticed with the proposed solutions. I don't mean to criticize you, though. It's common for users to be against significant UI changes. I'm just saying that we shouldn't let that fear stop us from adding new features.

@pkrasicki The "hacky" way of using filters to override the existing tile map to get the dark mode map is not good long term.

@mxdanger No one here is proposing it as a long term solution. But any changes made to the map (even if cartographers crate dark tiles) will be temporarily annoying to the users, because they will have to get used to the new thing. This is normal. The only thing we can do about that here, is adding a setting to let users disable the dark map and I included that in my UI proposal.

[AntonKhorev]

@gravitystorm

If we implement my Option 4b proposal, and if we implement some straightforward preferences

Your original description of Option 4b didn't include implementing preferences, it had "we shouldn't control those colours in dark mode", that's completely different now. It even looks like you agree to change this too: "We don't control what colours are used on the maps in light mode". That's what you'll get if there's an option for the map mode independent of the ui mode.

[rene78]

How about removing this brightness filter first and then continue your discussion? The map is very hard to use at the moment. Apparently lots of people agree on that.

[pkrasicki]

We can then revisit whether people want even further micro-control like choosing their own filters (to override the decisions of the cartographers).

@gravitystorm So it seems that you're not against having filters. You're just against applying them by default (even if it can be turned off). In that case, why not implement my UI proposal, but have the map always by light by default (in every theme)? And those who want a filter, they can enable it with 2 clicks. Of course, we would still need to discuss which filters to choose and test them. But isn't this way simpler than what you're proposing? We can even mark this as a beta feature, if you want.

[hlfan]

With the decision tree like this:

For each layer:
If light mode active use standard
If darkURL (dark tiles) use that
If local (layer-spanning) filter preference use that
If cartographers choice filter use that
Else default to filter: none

That would leave the user with at least four choices:

• Autodark (cartographers choice)
• Light (no filter)
• Dimmed (brightness/gamma filter)
• Dark (invert/hue-rotate)

Focusing on making these presets great may eliminate the need for micro-controls entirely.

However, four additional entries in the context menu like proposed in #4777 (following the predecessor of this discussion) seems to be too wasteful of the little space the map occupies on mobile already, I agree with @‌pkrasicki that the layer flyout panel is a better place for the radio buttons.

[tomFlowee]

@pkrasicki

If your opinion isn't just based on fear, then you should have no problem pointing out what specific issues you've noticed with the proposed solutions.

The main issue I see is that your proposal adds a 'theme' to a layer. Where a layer is what the front-end names the different tile styles (cycle map, transport map etc).
This is a division that makes no sense other than being reactionary to the 'darktheme' request.

A 'dark mode' (as this issue calls it) is from a user perspective a layer. Not a modification to a layer. This is one of those obvious things that is hard to convince a person of until they've tried it or until they did user testing to show unbiased new people one or the other design and register their response.
But I can make a small indication that may help create this understanding for the open minded persons:

• a layer has colors chosen by a cartographer. People pick a layer based on need or preference. This preference is orthogonal to dark mode needs.
• A layer has exectly one set of colors today. We can't rush making a second set for each. Which is exactly what would be needed if a layer is to have a dark/light mode toggle.
• The default map layer has practically no large areas of light. Most dark theme users will not find a need to change. On the other hand, the transport map has large sections of light and a I expect dark theme users would prefer a dark themed one. Point being: user preferences are for a layer, not for a dark theme regardless of layer.

[pkrasicki]

The main issue I see is that your proposal adds a 'theme' to a layer.

@tomFlowee It adds a theme to the whole map. The user can turn it on or off, but they have no control over specific layers.

A 'dark mode' (as this issue calls it) is from a user perspective a layer.

No, this is what I'm proposing:

A layer has exectly one set of colors today. We can't rush making a second set for each. Which is exactly what would be needed if a layer is to have a dark/light mode toggle.

We can easily change that with filters. There is no need to rush anything, we can test them for as long as we need. They don't have to be enabled by default if people really don't want to and we can even mark it as a beta feature if people want.

The default map layer has practically no large areas of light. Most dark theme users will not find a need to change.

Compare it to other map applications that have dark theme and you will see that it's too bright. Here is GNOME Maps for example:

OSM in light theme for comparison:

[Nekzuris]

On a grayscale, the default OSM light theme is actually 19% dark, whereas a typical light page with black text is around 3%.
The dark theme you showed is 90% dark.
Maps with hillshade like Tracestrack Topo are over 30%.

[hlfan]

I made a little utility to try out filter combinations more easily:
https://codepen.io/hlfan/full/GRVVGog
For convenient editing in the dev tools, the outputted filter is stored in a custom property and the filter is also applied to the SVG that holds the filters.

My first insight from using it:
The ÖPNVKarte didn't work well with the invert()hue-rotate(.5turn) method, as it made tram and subway lines barely distinguishable, but this goes away with another inversion method.

[Wilhem275]

and if we implement some straightforward preferences (e.g. auto/light/dark prefs for UI and/or maps) then I think most people will be reasonably happy with the outcome

That's what you'll get if there's an option for the map mode independent of the ui mode.

@gravitystorm @AntonKhorev

Is there any possibile conflict in giving users both a Dark UI toggle and a Dark Map choice?
The only one that comes to my mind is that some cartographers may oppose any alteration to their style, to the point of refusing any kind of dark mode for their layer (despite being given freedom to develop or choose one).

Is it possible to reach out to cartographers and ask for their opinion before further interface discussions? Maybe they just don't care and the problem doesn't even exist. Or maybe they're so much against alterations to their styles that no Dark Map will exist at all until someone develops one from scratch.

In this latter extreme scenario, it would all boil down to who's preference should prevail: users who absolutely want a Dark Map no matter how, or cartographers who absolutely want their style untouched.
I suspect cartographers have more power in this, as they may pull back their style from the project (o even escalate into a legal dispute?).
Users can always develop their own dark style, if they care about it... and remember we're talking about the extreme situation of an absolute refusal by the cartographer. If they develop a dark version or accept filtering, the problem doesn't exist.

In any case, this is one more reason why I would not implement a general Dark Map toggle overriding all styles, but instead present dark map styles to the user as individual choices in the Layers menu (no matter if the dark styles are native or by filtering, I'm not debating this).
If you implement a general toggle for all styles then you have to work out a way to override it for specific layers.
If the choice is via Layers menu... then it's just one less item in the list (and, remember, users can easily bookmark "Light OSM" and "Dark OSM" to launch whatever style fits them at any time of the day).

@Wilhem275 If your opinion isn't just based on fear, then you should have no problem pointing out what specific issues you've noticed with the proposed solutions. I don't mean to criticize you, though. It's common for users to be against significant UI changes. I'm just saying that we shouldn't let that fear stop us from adding new features.

@pkrasicki I think I already gave an extensive answer here.
To cut it short: developing a filter to adapt a single style is already a risky business, but it can work. What can't work is having one single filtering rule that can work well for ALL styles.

Map styles are based on the mathematical relationship between the colours of all different elements. Within a single style, they're already a large number of relationship to manage through one general set of rules.
Multiply this by all styles and their variations at different zoom levels, it becomes a staggering number with many conflicts.

It's not a fear, it's an absolute certainty that the output will be a mess 😄
Exactly what's happening here:

One size can't fit all.

As an alternative, you can develop specific filters for each style (and each zoom level...), this could work. But, can you guarantee to develop and maintain specific filters for each layer?
And by "develop" I mean also trialling them with a large number of users, not just launching into production a result satisfying you, me and four people in here. One by one, for each zoom level.
Seems quite a big job to me...

[hlfan]

One size can't fit all.

And by "develop" I mean also trialling them with a large number of users, not just launching into production a result satisfying you, me and four people in here.

You mean we shouldn't repeat what was done in #4712? /s

the output will be a mess 😄
Exactly what's happening here

Easy solution: use one of the crappy TTT dark styles and route the complaints about it to TTT.

[pkrasicki]

@Wilhem275

It's not a fear, it's an absolute certainty that the output will be a mess 😄
Exactly what's happening here:

I messed something up back then and couldn't be bothered to edit the screenshot afterwards, since it was just about showing the new options. Here is what the preview actually looks like with filter invert(1) hue-rotate(180deg):

There are only a few layers and it's easy to make filters. And no, we don't need separate filters for each zoom level, we don't even need a different filter for each layer, because some filters will work well for more than one layer.

[AntonKhorev]

And by "develop" I mean also trialling them with a large number of users, not just launching into production a result satisfying you, me and four people in here.

You mean we shouldn't repeat what was done in #4712? /s

And what do you think was done in #4712? Everyone had ~6 months to test the dark mode before it was launched into production, like this for example: #4663 (comment)

[AntonKhorev]

Is there any possibile conflict in giving users both a Dark UI toggle and a Dark Map choice?

I don't think there's a conflict, but it's another choice that's going to affect the implementation. We'll have to store the dark map setting for each UI color mode in this case.

[Nekzuris]

Everyone had ~6 months to test the dark mode before it was launched

I use OSM almost daily, from time to time on Discord and forums, I even contribute to iD occasionally, but I never saw any indication that a dark mode was in active development and about to be released.

[hlfan]

Everyone had ~6 months to test the dark mode before it was launched into production

Is this an "everyone who watched every single commit in this repo" everyone (which likely isn’t many), or was this communicated anywhere else?

[pkrasicki]

In 6 months no one has noticed anything wrong with it or realized that a better proposal already existed? Crazy.

At this rate it will probably take us 6 more months to get that filter removed and 6 years to discuss the 2 filters we're proposing.

[pkrasicki]

I made a little utility to try out filter combinations more easily: https://codepen.io/hlfan/full/GRVVGog For convenient editing in the dev tools, the outputted filter is stored in a custom property and the filter is also applied to the SVG that holds the filters.

@hlfan This is really good! Unfortunately it doesn't work for me in Firefox 128.4 ESR, but I just tested it in Chromium and it works really well. Is there a way to test different layers?

[hlfan]

Unfortunately it doesn't work for me in Firefox

Something to remember if SVG filters will be used: Firefox ignores filter definitions if they are behind a display: none.

Is there a way to test different layers?

Do you mean layering filters or changing the Map Tile URL under the heading Map Tile URL?

[AntonKhorev]

I use OSM almost daily, from time to time on Discord and forums, I even contribute to iD occasionally, but I never saw any indication that a dark mode was in active development and about to be released.

It was in active development, six months ago. It would have been difficult to miss it for anyone following this repo. Discord and forums are probably wrong places to look at in this case. But I made one related pull request in the iD repo. I also commented here.

Is this an "everyone who watched every single commit in this repo" everyone

Everyone who has the ability to find the pull request that broke their website.

In 6 months no one has noticed anything wrong with it

One thing was wrong, the filter was applied twice. Yes, no one noticed it in 6 months.

or realized that a better proposal already existed? Crazy.

This one: enable my rotation filter ignoring problems with hillshading?

[Nekzuris]

One thing was wrong, the filter was applied twice. Yes, no one noticed it in 6 months.

That’s funny because hundreds of people complained about it within the first hour it was live.

It doesn’t matter that it was applied twice, you and every other dev who saw it like that thought it was fine. You’re just using the fact that it was applied twice to justify reducing the intensity by half as a bug fix. But if it had only been applied once in the first place, you would have set the filter to 0.6.

[imagico]

I think i need to clarify something regarding:

For example, the maintainers of the current default map layer (openstreetmap-carto) have stated that they aren't planning on creating a dark version of their style

While this is true there are a number of additional points that are important here:

• we very much would like to see the style modified to allow easier adjustment to a different color scheme simply by swapping out the color definitions.
• we would also like to see style variations with substantially different color schemes being developed and deployed - and some OSM-Carto developers might even be intertested in working on such variations. We just think that this should be done in a separate project and not be intermixed with the main OSM-Carto development with its recognizable and equally cherished and hated trademark color scheme. Doing design work on OSM-Carto in a way that works well with our single color scheme is challenging already because of the very rich nature of the style and ther huge number of distinct colors it uses. Requiring style developers to always design for two different color schemes at the same time would substantially raise the bar in terms of skills required for doing design work and would therefore not be helpful regarding our goals.
• in contrast to other tile layers we, the OSM-Carto maintainers, do not have any control or even influence on the operational management of the tile service. We just maintain the style. Hence the decision if and how to create a new tile service with an OSM-Carto derived style with a darker base color is not ours.

If there is interest in the OSM-Community to have an OSM-Carto derived style with a darker base color on osm.org my suggestion would be to:

1. contribute to OSM-Carto to modify the style to allow easier color scheme adjustment. The main point that needs some work here is the patterns, because these are currently hand colored individually. A solution for this exists in the AC-Style (see here) and could serve as inspiration for developing something in OSM-Carto as well.
2. either organize a community project to develop an alternative color scheme as an add-on for OSM-Carto (substituting the color definitions) or organize funding to contract a style developer to design this.
3. get commitment from a tile hoster (could be the OSMF, but also a local chapter or a company) to host such a style.

But you should always bear in mind that this only makes sense if you indeed pursue the idea to have a style as rich and complex as OSM-Carto. If what you actually want is a simple garden variety roads + buildings + POIs + decorative landcover style with a dark color basis then OSM-Carto is not a good choice to start with.

[pkrasicki]

Something to remember if SVG filters will be used: Firefox ignores filter definitions if they are behind a display: none.

@hlfan Looks like it's fixed now.

Do you mean layering filters or changing the Map Tile URL under the heading Map Tile URL?

I wanted to test different layers like Cycle Map, Transport Map, Tracestrack. Can I do that with a URL change somehow?

This one: enable my rotation filter ignoring problems with hillshading?

@AntonKhorev You were the first person to point out that this a problem. So it took years to get any feedback. Now we have @hlfan's filters that we can use for the layers that have hillshading.