User Preferences implementation

[prushforth]

Perhaps a bit too much to ask as part of this issue, but it'd be really neat if we - at some point - could serve assets over a CDN. Apart from the potential performance benefits we could also use absolute URLs in our HTML markup examples, which would provide developers with a third easy-to-use installation alternative, as it is simply a matter of copy and paste. I have no personal experience in this area, but this resource may be useful: https://unpkg.com/#workflow.

Originally posted by @Malvoz in #493 (comment)

[prushforth]

Possibly related: linking the CDN idea to user preferences, by simulating what the browser installation gives you via implementing one (or more) browser extension(s).

One feature of such a configuration for example, might be that the polyfill could by default, say when installed raw via npm, support default en text strings, but when used / supplied via a user-installed extension (developed by us) that connected exclusively to the CDN version, the <mapml-viewer> would localize itself by strings installed with the extension, or perhaps on the CDN, so they could be updated, potentially. I am not fully familiar with this architecture, so posting for discussion.

Could such an architecture be used to simulate how users set up accessibility preferences, for example?

(Updated: internationalize -> localize)

[Malvoz]

Any sort of localization should be done independently of the resource location, probably based on browser settings (this is in line with how browsers localize <video> element buttons when I switch language in my browser between English/Swedish, for example).

Accessibility preferences can be honored by both the map viewer and authors using User Preference Media Features (via CSS @media or HTML media="").

[prushforth]

Oops yeah I meant "localize". The way I was thinking, the browser settings could be read by the extension using the API you found for us. It's not that the API is onerous, but if the localized strings for all languages had to be downloaded with the polyfill it might be "slow" (but mostly unnecessary). So perhaps they could be installed or at least cached as part of an extension installation.

[Malvoz]

but if the localized strings for all languages had to be downloaded with the polyfill it might be "slow" (but mostly unnecessary)

Honestly I don't think there's that much to localize. A set of aria-labels and title attributes in controls and those generated for the map and MapML elements (aria-label="Interactive map", aria-label="Feature"), and the context menu items.

Anything else inside mapml files is really the authors' responsibility, it doesn't matter which language my browser is set to, this very web page is always in English, unless I choose to translate it through the browser's context menu (albeit which can be hard to reach in fullscreen maps because we're using our own context menu - yet another reason for standardizing maps). OTOH I guess there is a use case for something like srclang, e.g.:

<layer- src="en.mapml" srclang="en"> // <mapml lang="en">...<featurecaption>hello</featurecaption>
<layer- src="sv.mapml" srclang="sv"> // <mapml lang="sv">...<featurecaption>hej</featurecaption>

There are probably other areas where we should focus on saving bytes, e.g. #153, and map data providers to compress images (I guess this may be a bit sensitive, don't want to distort/degrade the maps, but tools such as Lighthouse always complain about performance on web pages with maps due to large uncompressed images).

[prushforth]

Anything else inside mapml files is really the authors' responsibility, it doesn't matter which language my browser is set to, this very web page is always in English, unless I choose to translate it through the browser's context menu (albeit which can be hard to reach in fullscreen maps because we're using our own context menu - yet another reason for standardizing maps). OTOH I guess there is a use case for something like srclang, e.g.:

I always thought that Accept-Language was the way that resources were negotiated, your pointer to srclang is a new one on me, but I can see it's usefulness in the video context; I guess there must be a user interface for selecting among the track languages, built into the viewer. I wonder how that might work with maps; I suppose it could be built into the layer control, allowing users to select among different languages if they were available. This could be similar to layer alternate style, perhaps???

Going back to the topic of this issue, I'm mostly noodling about preserving user preferences across page loads/domains. This was something that Brandon asked me about, and I did confirm that we're interested in implementing user preferences. Just trying to figure out if an extension might be the way to do that. It's not so much that the bytes of the strings is too big so far.

[Malvoz]

Accept-Language

These are all valid methods of obtaining the user's preferred language. Different use cases. I think something like srclang is particularly useful to authors for referencing mapml files served on their own site.

I guess there must be a user interface for selecting among the track languages

I suppose it could be built into the layer control, allowing users to select among different languages

While the exposed user interface of media elements recommendation for UAs is to:

"include features to [...] change the display of closed captions or embedded sign-language tracks, select different audio tracks or turn on audio descriptions".

that's not actually implemented in any browsers yet. But that's been requested. I don't think we should go further than the Web has in that regard for the media elements. The browser settings already provide the UI for language preferences.

I'm mostly noodling about preserving user preferences across page loads/domains.

For language preferences Accept-Language, navigator.language , SVG systemLanguage , should all make this available. The problem is where the user preference itself is not supported in browsers, which is the case for the accessibility preference prefers-contrast for example, in which case you could argue that a mapml-viewer UI is useful.

[Malvoz]

I think we can close this umbrella issue for user preferences. There are other more narrow user preferences issues, and relevant issues in the browser extension.