Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Use case: View a map in dark mode or high-contrast mode #43

Open
AmeliaBR opened this issue May 27, 2019 · 12 comments
Open

Use case: View a map in dark mode or high-contrast mode #43

AmeliaBR opened this issue May 27, 2019 · 12 comments
Labels
discussion: use case a possible use case: should it be included? what should it say? status: placeholder there's a matching section heading / some text in the report, but it's far from complete

Comments

@AmeliaBR
Copy link
Member

This issue is for discussion of the use case “Customize the color scheme (light/dark or high contrast)”, its examples & list of required capabilities.

This is a user-focused use case: the ability to see the map in their preferred color scheme, maybe with the map tiles selected automatically based on their browser preferences.

@AmeliaBR AmeliaBR added discussion: use case a possible use case: should it be included? what should it say? status: placeholder there's a matching section heading / some text in the report, but it's far from complete section: map viewer Capabilities & use cases for declarative map viewer widgets labels May 27, 2019
@prushforth
Copy link
Member

prushforth commented May 27, 2019

This will be difficult to achieve on the client for all layers, however if the server provides such alternate styles, as is foreseen by the WMS 'style' parameter, it can be accommodated with a bit of effort from both client and server. In Testbed 14, we worked on incorporating WMS styles into MapML via <link rel=style> and it works pretty well. This is also supported in the GeoServer MapML Community Module.

Maybe a convention for high-contrast layers and / or dark mode style names would be possible? A browser could then do 'style negotiation' (based on the user's preference setting), like it currently does with projection negotiation. Or some other signal from the layer provider to the browser, possibly in the form of an additional <link rel=style> attribute e.g. visual="high-contrast" or something like that?

@AmeliaBR
Copy link
Member Author

For a markup implementation, my preferred approach would be something like the media attribute on a <source> element, where the web page author (or MapML author) can specify different sources for the layer based on different media queries (prefers-color-scheme or prefers-contrast). That way, the style name wouldn't need to be standardized, it could just be integrated into the URL or URL template.

In addition, there would need to be corresponding changes to text labels, controls, and so on.

In other words, when it comes to the capabilities required to implement this use case, there are a few items to consider:

  • the ability to swap between multiple layer sources based on user preference media queries
  • the ability to control styles of markers, vector features, and legends based on media queries
  • changes to the browser default styles of controls, markers, etc. based on preferences

@prushforth
Copy link
Member

@AmeliaBR I really like this proposal! I don't believe it's incompatible with what we've specified so far, I think you've put your finger on a great area to explore, which is specifically how to allow CSS to support client side map styles using media queries. I believe media queries could be useful in other areas of maps on the web, such as 'art direction', but that's an aside; back to this proposal.

Just a small point of clarification.

In the MapML proposal, <map>/<layer> is analagous to <video>|<audio>/ <source> except for the semantics of <source>, which is paraphrased: "pick a (single) source that works for you", whereas the <layer> semantics are "here are the layers of the map, stack and render them in document order". But diving inside the content retrieved by <layer>, we have specified that a set of <link rel='style'> plus a single <link rel='self style'> (the latter indicating/tagging the style of the current document) elements are user-selectable, although I don't believe that is mutually exclusive of this proposal. For an example, see the top-right map in this page, with a single layer labelled 'Coastlines' (in blue). The source document for that layer can be served by the server according to the 'Red example' or 'CubeWerx' named style, which the user can select by opening the layer control details toggle. Although I can't link to a demo page at the moment, this feature is also supported by the GeoServer implementation, and is planned for support by MapServer, too.

That way, the style name wouldn't need to be standardized, it could just be integrated into the URL or URL template.

On what element do you see the media attribute existing? Could the MapML document have multiple alternate <link tref> elements that would be activated by media query e.g. (and leaving out <input>s and the actual templates for brevity):
Using mozdev's page on prefer-color-scheme as a base for brainstorming:

<style>
@media (prefers-color-scheme: dark) {
  .day.dark-scheme   { background:  #333; color: white; }
  .night.dark-scheme { background: black; color:  #ddd; }
}
@media (prefers-color-scheme: light) {
  .day.light-scheme   { background: white; color:  #555; }
  .night.light-scheme { background:  #eee; color: black; }
}
</style>
<link rel=tile class=dark-scheme tref=...&request=GetMap&style=dark>
<link rel=tile class=light-scheme tref=...&request=GetMap&style=dark>

Am I understanding this correctly? I don't believe this would be incompatible with user-selectable layer styles, but could be a very excellent, if not essential, feature for accessible maps.

@AmeliaBR
Copy link
Member Author

I've been trying to focus on use cases without getting too deep into the specific markup proposals, but if we were to follow the model of video/audio, then a <layer> element would accept <source> (or equivalent) children that would provide alternative sources for that layer, as an alternative to directly setting a src attribute.

@prushforth
Copy link
Member

Interesting idea. The HTML author could have control over the map appearance, conditioned on the users preference.

If the map author had similar controls, it could be important.

@prushforth
Copy link
Member

Say you had an HTML element like this, assuming could have child elements:

<style>
@media (prefers-color-scheme: dark) {
  .day.dark-scheme   { background:  #333; color: white; }
  .night.dark-scheme { background: black; color:  #ddd; }
}
@media (prefers-color-scheme: light) {
  .day.light-scheme   { background: white; color:  #555; }
  .night.light-scheme { background:  #eee; color: black; }
}
</style>
<map ...>
  <layer src="https://always-included-basemap.example.org/mapml"></layer>
  <layer class=dark-scheme src="https://dark.example.org/mapml/'></layer>
  <layer class=light-scheme src="http://light.example.org/mapml"></layer>
</map>

Would that work? Do you need to allow multiple options per layer?

@cmhodgson
Copy link

cmhodgson commented May 28, 2019

The style example you borrowed from the mozilla dev site is concocted specifically to allow you to compare the the differences in day and light mode. Normally you would use the same classes, in both schemes, but change the properties. To take the same example and make minimum changes:

<style>
@media (prefers-color-scheme: dark) {
  .dark-scheme { visible: true; }
  .light-scheme { visible: false; }
}
@media (prefers-color-scheme: light) {
  .dark-scheme   { visible: false; }
  .light-scheme { visible: true; }
}
</style>
<map ...>
  <layer src="https://always-included-basemap.example.org/mapml"></layer>
  <layer class="dark-scheme" src="https://dark.example.org/mapml/'></layer>
  <layer class="light-scheme" src="http://light.example.org/mapml"></layer>
</map>

I'm making up the visible attribute here, but something like that. The day/night from the original example where meant to refer to various elements within the layer, however if we are talking about a image-based map, you aren't going to be able to specify those details. In the case of a vector-data map, the layer itself wouldn't need to have any class. Ideally in my mind, the vector data layer would have its own style link, which would provide its own styling and do its own media selection.

What gets complicated is trying to put layers from different providers on the same map if they haven't already been coordinated (color overlaps, conflicting contrast, etc) because just the options of "dark" and "light" are not enough to resolve a 3-way conflict. In fact, it isn't even clear how they work on a 2-way conflict, typically you need the symbology to contrast with the basemap, eg. if you have a dark-mode basemap, you want lighter icons etc, but if you have a light-mode basemap, then darker icons work better, the classic example is switching between a typically dark imagery-based basemap, with lots of grey pavement, dark green trees, and dark blue water, and the lighter street basemap, with white, pale yellow, pale green, and pale blue as typical fill colors. Then you want placemark icons to stand out well against the backdrop - are the darker icons that stand out well in front of the light street basemap considered to be dark mode or light mode? And what mode are the semi-transparent polygon area overlays?

Cartography is hard enough with a fixed set of layers and a single color scheme, introducing support for multiple color schemes AND linking in layers from different sources, is going to be challenging. I would suggest that the user needs to be able to configure these things, and since we already have the concept of style, we could just provide a default, here is an idea with a made-up mapml layer-specific css property "default-style":

<style>
@media (prefers-color-scheme: dark) {
  .someClass { default-style: dark; }
}
@media (prefers-color-scheme: light) {
  .someClass { default-style: light; }
}
</style>
<map ...>
  <layer src="https://always-included-basemap.example.org/mapml"></layer>
  <layer class="someClass" src="http://example.org/mapml"></layer>
</map>

The idea is that the layer would know to request the specified default-style, but then the user would be able to switch it as they prefer. This seems to find a middle ground between taking advantage of the power of the color-scheme media selectors and the power of the already existing style concept from GIS (OGC WMS, ESRI, etc).

@prushforth
Copy link
Member

if we were to follow the model of video/audio, then a element would accept (or equivalent) children that would provide alternative sources for that layer, as an alternative to directly setting a src attribute.

I'm making up the visible attribute here,

The <link> and <source> elements have broken ground here in that they support a media attribute to specify if the link or source is included or not in the document, so this might be conceived to work for the prefers-color-scheme media feature as well, so that it's not so much a CSS thing as a parser feature?

<map...>
  <layer media="prefers-color-scheme: dark" src="..."></layer>
  <layer media="prefers-color-scheme: light" src="..."></layer>
</map>

It seems there may be a subset of media features that could apply to maps too (e.g. motion, contrast, hey maybe cartographers could think up some that are really map specific). It's not clear to me, for the prefers-color-scheme feature, how the browser decides between light and dark if the user has no preference and the author hasn't specified a value for no-preference. Maybe you can specify a feature > 1 time ?

<layer media="prefers-color-scheme: light; prefers-color-scheme: no-preference" src="..."></layer>

@cmhodgson
Copy link

I like this approach.

Based on this: https://developer.mozilla.org/en-US/docs/Web/CSS/@media#media-query-list
I think the multi-condition media query syntax might be this:

<layer media="(prefers-color-scheme: light) OR (prefers-color-scheme: no-preference)" src="..."></layer>

I think the the default style issue could then be addressed as follows:

<layer media="NOT (prefers-color-scheme: dark)" src="http://example.org/mapml?style=light"></layer>
<layer media="(prefers-color-scheme: dark)" src="http://example.org/mapml?style=dark"></layer>

The result being that you get a reference to the same mapml src but with the layer parameter set differently which would allow the usual style controls (if present) to change the style. All very controllable and in line with the HTML approach.

@prushforth
Copy link
Member

The trouble with all of this is: now I have a new hammer :-)

@AmeliaBR AmeliaBR removed the section: map viewer Capabilities & use cases for declarative map viewer widgets label Jul 25, 2019
@Malvoz
Copy link
Member

Malvoz commented May 23, 2020

Given that there are several user preference-based media features:

should we rename this use case to cover all preference-based media features, or should we have separate use cases for those?

@Malvoz
Copy link
Member

Malvoz commented Nov 4, 2020

@prushforth wrote #43 (comment):

If the map author had similar controls, it could be important.

The proposed mechanism in w3c/csswg-drafts#4162 should enable that.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
discussion: use case a possible use case: should it be included? what should it say? status: placeholder there's a matching section heading / some text in the report, but it's far from complete
Projects
None yet
Development

No branches or pull requests

4 participants