Skip to content
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

Capability: Embed an interactive map viewer, using HTML markup #137

Open
Malvoz opened this issue Sep 9, 2019 · 7 comments
Open

Capability: Embed an interactive map viewer, using HTML markup #137

Malvoz opened this issue Sep 9, 2019 · 7 comments
Labels
discussion: capability a specific capability or feature: should it be included? what details? should it be a requirement? section: map viewer Capabilities & use cases for declarative map viewer widgets status: editor's draft there's a draft section in the report that corresponds to this discussion

Comments

@Malvoz
Copy link
Member

Malvoz commented Sep 9, 2019

This issue is for discussion of the required map viewer capability “Embed an interactive map viewer, using HTML markup”.

@Malvoz Malvoz added discussion: capability a specific capability or feature: should it be included? what details? should it be a requirement? section: map viewer Capabilities & use cases for declarative map viewer widgets status: editor's draft there's a draft section in the report that corresponds to this discussion labels Sep 9, 2019
@Malvoz
Copy link
Member Author

Malvoz commented Sep 11, 2019

@AmeliaBR, @prushforth

Parallels have been drawn between the map viewer model and <iframe>. In relation, there is a proposal for the <portal> element which is receiving some push-back in this TAG design review (comment), and so I wonder if this could indicate implications or otherwise affect the establishment of a model for the map viewer?

@prushforth
Copy link
Member

Good question, answer TBD. I think a map viewer that allows composition / layering across origins will require us to come up with a good story. Hopefully we can get some contributions, or at least inform our own contributions from the experience and designs from people with experience in designing similar things in iframe and portal contexts. Portals and iframes are more generic containers than maps, so I believe our biggest challenge will be selling a highly specific type of container, like a map viewer.

All the great work this community is currently doing will be our business case!

@AmeliaBR
Copy link
Member

Yes, one of the more difficult things to spec will be the model for creating fully interactive, style-able layers from external files. Another relevant model from that perspective is the SVG <use> element (which is currently restricted to same-domain external files, but there is discussion in w3c/svgwg#707 about extending it to cross-origin content).

@prushforth
Copy link
Member

If I understand this correctly, layers in a map viewer, were they to be loaded via a URL (as in layer src), would have to be their own browsing context, if they were to be able to load resources, such as tiles or WMS/image requests (which is pretty important for map layers).

@prushforth
Copy link
Member

prushforth commented Sep 25, 2019

I think this issue is about how an HTML author would go about adding a map viewer to their page. I think they should be able to do so by adding an element, in an analagous manner to the method they can use to embed <video> players.

@prushforth
Copy link
Member

This comment doesn't apply to the PR, but to the text about the existing implementations.

Not to be too hard on the -embed list, but they are all JavaScript API dependent, too. The commentary seems to imply that the JavaScript dependency only applies to custom element wrappers of mapping libraries, and that the embeds are declarative except for the fact that they rely on configuration in the source URL. In fact, ALL the embeds are entirely animated by their associated JavaScript APIs internally.

@Malvoz
Copy link
Member Author

Malvoz commented Nov 6, 2020

#137 (comment)

Not to be too hard on the -embed list, but they are all JavaScript API dependent

Yes but the capability is about embedding a web map with HTML code alone, which holds true from the point of view of the HTML author (so separate from Capability: Display a basic map without JavaScript).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
discussion: capability a specific capability or feature: should it be included? what details? should it be a requirement? section: map viewer Capabilities & use cases for declarative map viewer widgets status: editor's draft there's a draft section in the report that corresponds to this discussion
Projects
None yet
Development

No branches or pull requests

3 participants