-
Notifications
You must be signed in to change notification settings - Fork 12
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
Comments
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 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 |
For a markup implementation, my preferred approach would be something like the 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:
|
@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,
On what element do you see the media attribute existing? Could the MapML document have multiple alternate
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. |
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 |
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. |
Say you had an HTML element like this, assuming could have child elements:
Would that work? Do you need to allow multiple options per layer? |
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:
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":
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). |
The
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 ?
|
I like this approach. Based on this: https://developer.mozilla.org/en-US/docs/Web/CSS/@media#media-query-list
I think the the default style issue could then be addressed as follows:
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. |
The trouble with all of this is: now I have a new hammer :-) |
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? |
@prushforth wrote #43 (comment):
The proposed mechanism in w3c/csswg-drafts#4162 should enable that. |
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.
The text was updated successfully, but these errors were encountered: