New feature proposal: new capabilities and features in HTML to support web maps

[prushforth]

Hi there, we (the Maps for HTML CG) want to share our ideas with the WHATWG community, and it has been suggested that opening an issue here might help facilitate the process of getting feedback on these ideas for an extension to the Web Platform. Such an extension might result in the requirement to add and / or extend some parts of HTML, along the lines of the subject of this issue.

We recently published a report from our 2020 Workshop, which brought together mapping stakeholders from around the world, and it's worth reading the executive summary and perhaps more of it if you're interested (the quotes are particularly important). The conclusion of the workshop community is that we should pursue incremental standardization and implementation of maps and location in the Web Platform, starting by defining what the primitives that we need are.

The workshop participants uncovered a number of pain points for Web mappers:

• the accessibility of Web maps is not standardized, leaving disabled users with widely variable experiences and utilities
• good Web map performance is extremely difficult to achieve and is relatively unsupported by browsers. Having "good performance" built in will allow our community to focus less on client rendering and contribute more to the Web Platform.
• Web map internationalization does not yet benefit from the huge efforts that have been invested by browsers in international text rendering (because map rendering is script-centric)
• CSS is not yet directly relevant to Web mapping since there's no platform-standard way to represent maps and map features (i.e. roads, sidewalks etc.).
• 2D Web maps that represent real-world coordinates are on the spectrum of features leading to Augmented Reality. Start simple, and useful!

Our community has been iterating on Use Cases and Requirements, the "MapML" proposal (map semantics in HTML) and custom element polyfills. We are tracking our progress through the UCR Fulfillment Matrix, which relates the UCR and various Web map implementations, with the objective that we are able to eventually define a complete set of requirements together with a coherent and acceptable proposal (specification) on how to incrementally implement those requirements.

Request for Feedback

Our community group invites feedback from WHATWG members on the process, documents and results that have been developed so far. Specifically, are we aligned on the use cases? We would also like to collaborate with browser developers so that some platform use cases that are particularly important to map rendering don't leave maps out of scope, for example zoom and pan, which seems to be a cross-cutting capability that could greatly apply to maps if taken into account.

It's our intention to further engage with the mapping, accessibility and browser developer communities. We have seen evidence of openness to pursue standardization from some important mapping and accessibility stakeholders and we would like to begin to engage with the browser development community through this issue.

Thanks in advance, on behalf of the Maps for HTML community.

[prushforth]

If there is no implementer interest in implementing maps in HTML, could someone please explain why that is the case? We have an active community and well founded support. Standardizing accessibility of Web maps would seem an obvious win for users. Finally, maps are everywhere! What approach can we use to move this effort forward? Thank you.

[pshaughn]

I'm just a random interested Web author, so don't take this as definitive: From what I've seen, new-feature proposals that get implementer interest tend to get it by pitching the idea to the big implementers (Chromium, Firefox, Safari) individually through the implementers' own processes, not via a WHATWG proposal. The WHATWG proposal tends to be where the different implementers work out how to align their implementations, not the initial starting point of a new feature.

[Malvoz]

The process is quite clear: https://whatwg.org/faq#adding-new-features.

7. Get multi-implementer interest in the solution. This means a commitment from two or more browser engines to implement and ship your feature. [...]

By that definition, it seems it is too early to expect implementer interest. Web maps is a complex feature, and as it stands, MapML hasn't been specced to the level of detail necessary for actual implementations.

What approach can we use to move this effort forward?

A clearer specification and explainer. And continued iteration over the Use Cases and Requirements is imperative for standardizing web maps (cc @AmeliaBR).

As @zcorpan / @bocoup stated in their position statement (emphasis mine):

we reviewed the proposals from the Maps for HTML Community Group. We found that the explainer and the technical specifications had fundamental issues and may need significant changes, but the Use Cases and Requirements document is very much on the right track.

Although both the spec and explainer has been improved since, that statement still holds true. @zcorpan also raised multiple issues on the MapML spec and reviewed the explainer - feedback which we're yet to fully address.

[zcorpan]

We discussed this in the WHATWG triage meeting today. Here's what I captured as feedback from @domenic @chrishtr @mfreed7 et al.:

Since many use cases are solvable today, it's hard to evaluate proposals around the use cases alone.

It would be useful to discuss limitations of existing JS-based solutions, and what primitives are missing. e.g.

• supporting gestures like pinch, swipe...
• things that cause perf problems (e.g. override page scrolling)
• things that make it difficult to make maps accessible

It would be espesially interesting to hear from JS maps library devs about missing primitives.

Open UI has created a precedent for standardizing widgets without necessarily changing browsers. That could also be a strategy for maps.

[zcorpan]

I changed the title of this issue since I noticed there was some confusion from the issue being broader in scope than proposing 2 elements.

[Malvoz]

it's hard to evaluate proposals around the use cases alone.

It would be useful to discuss limitations of existing JS-based solutions, and what primitives are missing. e.g.

• supporting gestures like pinch, swipe...
• things that cause perf problems (e.g. override page scrolling)
• things that make it difficult to make maps accessible

Use cases have one or more Required capabilities, ultimately I think these are the ones that should be evaluated. Each capability (Map Viewer Widget Capabilities / Client-side Mapping API Capabilities) should convey information such as missing primitives and limitations of capabilities in existing JS-based solutions. And tags related to performance and accessibility (and more) should be used (as applicable) along with appropriate descriptions.

All use cases and capabilities have links to GH issues for discussion. So for example both the pan and zoom capabilities mention gestures, supposedly the corresponding GH issues should be used to discuss gestures as they apply to each capability.

I think the use cases and capabilities (and their properties) are generally underdefined atm, which may lead to some confusion. Perhaps it'd be easier to evaluate proposals once the Summary of Requirements (a summary of capabilities concluded as requirements) is available.