Web-Map-Custom-Element
Web-Map-Custom-Element copied to clipboard
Replace popup implementation with popup event
In discussions with @shepazu, he convinced us that an interactive popup for maps is likely to be one of the most difficult things to negotiate with browser developers, since it is a complex topic with accessibility requirements that likely needs to extend beyond maps use cases. Furthermore, there are discussions happening in the HTML standard that suggest a popup might become an element supported by browsers independent of maps, so maps could work towards using the results of that work and not duplicating it.
So, in accordance with that thinking, this issue is for discussion of the idea of removing a map-based popup, and replacing it with a popup event. The idea would be that the function that handles the event could create a UI appropriate to its needs, a sidebar, a toast, a popup, whatever was considered appropriate by the author. In this project we could develop a small library to handle the popup event to fit the needs of a demonstration.
Further, it may provide us opportunities for enhancing the interactivity of features returned by query links, for example, which could be used not only for popups (as they currently are, exclusively) but also for links. Currently a feature geometry can be a link, or it can have a popup, but not both; we are working on a way to return a feature with a link (by default there's currently always a popup).
When we do move to this mode, we will be in a better position to support Feature Indexing, in that feature captions that are loaded into the index can be either linked features OR popup-creators, either way the user will expose more information when activating. Currently every feature returned by the reticle is a popup creator.
@erictheise have you noticed this issue? The idea here is to simplify the overall MapML proposal by removing the need to propose UI that is associated to popups and replacing that in the proposal with an appropriate map popup
event(s) API, if possible. I was persuaded in my discussions with @shepazu (not through Doug's explicit efforts to persuade me, but by my own conclusion) that negotiating maps in HTML will be made too hard /too big by bundling more requirements into the one proposal than is strictly necessary. Many others have asserted variations on this theme, by saying the overall proposal should be broken down into "primitves". As such, I think the popup
event API may well be such a primitive.
In light of the fact that there is an ongoing effort led by WHATWG members to specify, polyfill and implement a <popup>
element, I felt that it would be appropriate to reduce our requirements in this area, in the hope that the Web platform will be able to readily provide its own popup event handler in actual implementations, perhaps based on an evolution of the eventual <popup>
element. Even if that does not turn out to be true, it is already true that popups don't suit every map use case, and so there is a need to consider an underlying API (the events, I think) first, and to potentially provide a separate and accessible custom element that implements popup behaviour that handles map popup
events.
Introducing a <popup>
element is a great idea, glad to learn people are working on that. I didn't find any mention of maps, charts, graphs in their documents so I went ahead and asked a "dumb" question in the issue you linked @prushforth. Fall term 2021 seems optimistic for resolution of this issue though!
Fall term 2021 seems optimistic for resolution of this issue though!
I don't mean that the <popup>
element will be ready by this fall.
I mean that we might be able to define the map popup event API, and perhaps a custom element that will handle it, so as to have identifiable parts to the proposal that don't all have to be addressed at once. The point is to "find the joints" of this problem and make it so we can propose and develop a solution in stages. Anyway I wanted to ensure you are aware of this notion.
I didn't find any mention of maps, charts, graphs in their documents so I went ahead and asked a "dumb" question in the issue you linked
Not dumb, very well asked. They specifically asked for feedback over here, where it is more likely to get a response, perhaps.
https://github.com/openui/open-ui/pull/355