Implement map content selection based on media queries associated to map-link

[prushforth]

Implement ideas in Maps4HTML/HTML-Map-Element-UseCases-Requirements#43 and #546 and Maps4HTML/HTML-Map-Element-UseCases-Requirements#256
Would likely replace announcing of location: per #552

[prushforth]

One relevant specification for this feature is Media Queries Level 5, which specifies a set of prefers- user preference related query features, although there seems to be some doubt as to their fitness for the Web.

None of the other media features seems to fit with the core requirement here, and media types seem to be deprecated.

I propose to prototype a prefers-map-content or similar construct, with a set of values that we should discuss below.

Inital thoughts on domain of values for prefers-map-content

• image - user prefers that the map content be retrieved / painted using the WMS model
• tiled-image - paint the map using image tiles
• feature - represent layers as vector data if possible. This could be used to improve a11y for image-based maps
• vector-tile - represent map content with vector tiles, if possible.
• table - present data as a table of features, sorted ascending by distance from map location
• no-preference - prefers to retrieve no remote content for maps

[prushforth]

Other potentially useful media features and possible values and types
map-projection: OSMTILE, CBMTILE, WGS84, custom, discrete
map-zoom: <integer>, range type
map-scale: <integer>, range type

[prushforth]

Media query parser implementationss: https://github.com/tbjgolden/media-query-parser and https://github.com/csstools/postcss-plugins/tree/main/packages/media-query-list-parser

[prushforth]

I was really hoping to shoe-horn bbox media queries through this facility, but this is out of bounds as far as the CSS grammar / parser goes, at least for now. The reason is that media feature values (<mf-value> in the linked spec) cannot contain commas, and representing individual corner coordinates of the bounds / map extent as independent media features would not work as far as how media query solving works (each predicate is individually assessed as true/false/unknown, without having the complete state required to fully evaluate bbox overlaps).