Consider making MapML an extension to HTML #70
Comments
I don't have enough experience in this domain to understand the security concerns, but it seems that some level of change must be ongoing as the vocabulary changes. I hope that minor changes can be accomplished for maps as a high-level feature in a single (group of) changes.
Yes, the intent has always been to achieve maximum compatibility with HTML. My understanding of this compatibility has evolved over the course of this project, to the degree that I now believe MapML may be a good marketing term (YMMV), but it should actually be part of HTML, so that it comes with a DOM API that allows it to be programmed by Web devs, when included inline in HTML. I appreciate that this may cause confusion to a reader such as yourself, and I'll work towards removing that confusion for developers who follow you.
Agreed.
OK. We haven't registered a MIME type yet. We will have to update the spec and the polyfill, as well as the servers (GeoServer, MapServer) that will support maps in HTML. I believe the use of I believe it does require it's own MIME type, so that browsers know what to do with it when the context isn't fetching a layer in a map. i.e. it might be possible to synthesize a surrounding html, head, body, map and layer as it does with an image file. Even when the context is fetching a layer within a map, it might even be useful to render text/html even on the map, if the rendering mode was by coordinate-specific means vs normal html rendering. We should discuss this more, but I think it could be a valuable general situation / use case.
OK, I worry a bit that we are relying too much on the MIME type if we don't have a <!doctype mapml> or root mapml element, but maybe that is misplaced concern, as I don't fully understand what these <!doctype html> and root html are used for.
Yes. Again I'm a little fuzzy about the implication of not having a doctype and relying solely on the MIME type.
Yes. In HTML, I believe html, head and body are optional, supplied by the parser if not present.
Does this need to be specified in the MapML specification/proposal? I think yes, but not sure.
Yes, agreed.
OK. What about specifying the meta values that we need? Where should those go?
We have a few requirements around link, some of which seem to fit in with how link is used generally, others which may be more surprising. Lots to discuss, I guess :-)
We started out using
Someday, not today, it would be cool to be able to use the map as an input method for forms, enabling declarative geospatial content creation, e.g. <input type=location subtype=linestring ...>
Was trying to re-use related stuff from HTML. The user input is gestures for zoom/pan events (move, moveend) however I can see why you think it should be something else.
These probably require a demo to show what they are proposed to do for maps. They are mostly used to populate the layer control entry for the layer with values that control the requests that are made to a map or tile server, for example to allow the user to view the map layer at a particular date, or elevation, or for example to view highways only from a roads layer. Maybe when you see how these are used to control the content of the map, using
Maybe
These come from GeoJSON, but I was thinking recently that
This is a pretty big discussion on its own, I think. The reason attributes aren't adequate for geometries is because we need to be able to use CSS selectors on whole or part geometries or even parts of geometry parts, in order to a) style them differently/appropriately than the rest of the geometry and b) make hyperlinks out of their constituent parts or parts of their constituent parts. We really want to use CSS and not invent whole new layers of abstraction; I think we want to work with the SVG community to work on common requirements for CSS. Sometimes SVG is perfectly adequate for map annotations / graphics / legends, but generally is difficult to use for map features. SVG, while great, and while it may allow us to simulate / polyfill spatial feature geometries by allowing us to generate Attributes (like those used by svg paths) can have their own grammar, but they can't contain markup. We need to include markup in feature geometries for the reasons cited above. |
See whatwg/html#2253 (comment) However, new elements can be added to HTML without changing the parser, if the parsing behavior of unknown elements is OK (which is, parse like |
OK cool. I suggest filing an issue at whatwg/html so they are aware of this proposed extension to HTML.
|
Looks like I was mistaken here. :-) I thought +foo was a convention, and +xml was the only one with special handling, but now I found https://tools.ietf.org/html/rfc6839 I undecided right now if +html really makes sense. Maybe it doesn't and text/mapml is right.
OK, yeah. This would need to be defined in HTML analogous to https://html.spec.whatwg.org/multipage/browsing-the-web.html#read-media
OK. |
Funny you should mention that, as we've been developing static tile layer code lately. We imagine that it might be useful to have content in a tile, for example > 1 |
Is that jumping the gun? Anyway I guess I jumped it some time ago, but maybe it's time to bring some new energy to the process. |
|
No it seems better to give the HTML folks a heads up about proposals that extend HTML early. If this was the plan all along, it's not early anymore, but better now than later. :) |
Filed #72 |
Yes. (Filed #73) |
What are those? I don't see meta names specified. But you can specify those in MapML -- only the name and the processing associated with it. See https://html.spec.whatwg.org/multipage/semantics.html#standard-metadata-names for the currently standardized meta names in HTML. |
The |
|
@zcorpan A question I have about processing a text/mapml response received from.a 'layer src' request is: how will HTML elements that aren't in the MapML vocabulary of HTML be rendered? We have to have a proposal for that if it's all to be handled with no change to the parser. |
There was a similar consideration for HTML Modules to use a |
|
@zcorpan wrote:
We've updated the MapML spec to say that MapML documents are in the xhtml namespace (xmlns="http://www.w3.org/1999/xhtml/"), and removed references to MicroXML. I've updated the demo service to serialize MapML documents into that namespace. We've also tested the polyfill to ensure that it supports the namespace version of MapML, and we've updated the GeoServer MapML Community Module to serialize MapML documents in the xhtml namespace.
Robert and I agreed we should have a community group discussion asap to help us decide what to put into this issue for the best possible response. Please vote for the meeting time. |
|
Here are the meeting details. Add your comments below for discussion there, if applicable. |
|
We've moved the xml vocabulary into the xhtml namespace. We opened the issue with WHATWG. Cleaning up and closing. |
Meanwhile, in the
mapelement proposal, for thelayerelement, says:MapML can't be MicroXML and also be embeddable in HTML (without significantly changing the HTML parser).
MicroXML implies that MapML elements are in no namespace. Apart from RSS, languages that browsers support use namespaces.
Changing the HTML parser to support a new class of foreign content seems unlikely to happen for MapML, or even for anything. Even minor changes are usually met with resistance from implementers, due to security concerns.
With https://github.com/prushforth/htmlparser and https://www.w3.org/community/maps4html/2019/12/09/the-design-of-mapml/ , I've understood that the intent is to change MapML to be more "like HTML", instead of MicroXML.
If so, that should be formalized in the MapML spec. Further, if the intent is to be able to embed MapML inline in HTML documents, I think the best way to do that is to make all MapML elements be HTML elements directly, and MapML documents be HTML documents. (XML serialization is still possible, like with HTML.)
The implications would be:
text/mapml+htmlas the MIME type, if MapML needs its own MIME type. Otherwise usetext/html.<!doctype html>(or maybe allow omitting it for new MIME type)html, containingheadandbody.HTMLElement, orHTMLExtentElement : HTMLElementetc.head,title,base,meta: these don't seem to have MapML-specific processing. Remove from the MapML spec.link: ?extent: if this is intended to reuse form submission, maybe useforminstead? (I'm not sure why MapML needs form submission?)input: this doesn't seem to be a widget that expects user input; suggest minting a new element name.datalist,label,select,option: ?image: the HTML parser treats<image>as a macro and changes it to<img>. New element name?feature,properties: don't clash with anything, but are a bit genericgeometry: doesn't clash, though this seems to be yet another way to represent 2d geometric shapes on the web. We have SVG,<area>, canvas 2dcontext API, Geometry APIs. This seems most like<area>, except it's only geometry data without hyperlink.coordinates: why is this an element, and not an attribute ofgeometry?The text was updated successfully, but these errors were encountered: