Repository navigation
Use of "Metadata content" in <layer>'s content model #84
Description
Content model:
If the src attribute is present: Empty. If no src attribute is present: Metadata content describing nested Map Markup Language content
"Metadata content" is a specific list of HTML elements, plus "Elements from other namespaces whose semantics are primarily metadata-related (e.g. RDF) are also metadata content."
https://html.spec.whatwg.org/multipage/dom.html#metadata-content-2
If you want to allow only MapML elements here, don't use "metadata content".
Activity
prushforth commentedon Jul 3, 2020
When you create MapML content in the layer DOM this way, you're going to need sometimes to establish metadata about the content, such as the zoom range and bounds it should be displayed in, which I think we are thinking could be provided by the
<meta>element, which otherwise might have been provided in the<head>element of the document fetched fromlayer@src.Maybe this means we need to define a new content category ('map')?
prushforth commentedon Apr 4, 2022
For instance, see the example in this page. The second <layer-> element has "inline" metadata content, plus MapML described by the metadata. I can imagine how some the current specific list of elements defined as "metadata content" apply (e.g. base, meta, link, style, title) but not others (e.g. script, noscript and template).
What do you suggest?
zcorpan commentedon Apr 4, 2022
What is the exact list of elements you want to allow in
layer?Malvoz commentedon Apr 4, 2022
I believe the layer element (without a
srcattribute that is) allows:<meta><link><style><extent><input><datalist><label><select><option><feature><featurecaption><properties><geometry><a><coordinates><image><tile>i.e. allowed children are: a subset of HTML metadata elements,
extent,feature, andtile.@prushforth does this look correct to you?
prushforth commentedon Apr 4, 2022
Metadata content
Looks pretty good. Add:
I don't think we have thought of a map-specific use for <script>, <noscript> or <template>, but if they fill out the role of "metadata content", is it simpler to allow them or to create a new content category?
Not metadata content
FWIW I think <image> is an anachronism, and we could get rid of it.
We would eventually like discuss how to (use CSS to) absolutely position and style other HTML content that gets rendered on the map; we would like to allow such elements to be rendered and panned/zoomed (as suits the author), or hidden (depending on map scale, perhaps), with the map in a standard fashion.
Malvoz commentedon Apr 4, 2022
I can see the usefulness of these elements in mapml documents, but since we're discussing the layer element's content model (in an HTML document):
<base>element per document. So authors may as well use it in HTML<head>?I don't suppose we're intending to change the definition of HTML
<base>? Am I missing something?<title>needed (outside of mapml documents)? We already have<layer label="">.I suppose it could be allowed, and
labeltake precedence, as is the case with external mapml documents?Perhaps it's time to discuss #210?
For MapML documents I think it's been said they're a security concern, but maybe the correct thing to do is allow them, and leave it up to authors to use CSP
script-srcaccordingly?Oops, I've corrected my comment.
prushforth commentedon Apr 5, 2022
OK, I didn't realize that. We include <map-base> element processing when processing a remote text/mapml response in our polyfill, and the processing is very naive compared with the HTML spec. Further, while the polyfill does process inline MapML, it doesn't use the distinction of inline vs remote document in its logic, such as whether to ignore a found <map-base> element, it just uses the provided URL as a base URL to resolve other found URLs against (which obviously does not conform to HTML). We need a way to specify some (layer) metadata inline, without having to have an inline <map-head> element, which is also obviously not an HTML construct.
The polyfill behaviour has changed about whether a provided <title> will take precedence, IIRC. Currently, a map author-provided <map-title> takes precedence, with a fallback to <layer- @Label="..."> regardless of whether the content is inline or a remote document. That could be wrong, fwiw. I was thinking about honouring the intentions of the cartographer / map author in that implementation.
Getting back to @zcorpan's original comment:
We want to allow some of the elements categorized as "metadata content", plus a set of map content elements. Robert's comment provides the current respective element lists.
Maybe we should coin specification terms such as "map (or layer) metadata content" and "map content"?