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?
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!
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).
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).
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.
This comment doesn't apply to the PR, but to the text about the existing implementations.