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.

Sign up for GitHub

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

Jump to bottom

Use of "Metadata content" in <layer>'s content model #84

Closed
zcorpan opened this issue Jun 29, 2020 · 7 comments · Fixed by #252 · May be fixed by #230
Closed

Use of "Metadata content" in <layer>'s content model #84

zcorpan opened this issue Jun 29, 2020 · 7 comments · Fixed by #252 · May be fixed by #230

Comments

@zcorpan
Copy link

zcorpan commented Jun 29, 2020

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".
@prushforth
Copy link
Member

If you want to allow only MapML elements here, don't use "metadata content".

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 from layer@src.

Maybe this means we need to define a new content category ('map')?

@prushforth prushforth transferred this issue from Maps4HTML/HTML-Map-Element Jul 22, 2020
@Malvoz Malvoz mentioned this issue Oct 5, 2021
Open
@prushforth
Copy link
Member

If you want to allow only MapML elements here, don't use "metadata content".

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 from layer@src.

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).

If you want to allow only MapML elements here, don't use "metadata content".

What do you suggest?

@zcorpan
Copy link
Author

zcorpan commented Apr 4, 2022

What is the exact list of elements you want to allow in layer?

@Malvoz
Copy link
Member

Malvoz commented Apr 4, 2022 •
edited
Loading

I believe the layer element (without a src attribute that is) allows:

i.e. allowed children are: a subset of HTML metadata elements, extent, feature, and tile.

@prushforth does this look correct to you?

@prushforth
Copy link
Member

Metadata content

  • <meta>
  • <link>
  • <style>
  • perhaps other non-scripting metadata elements, though AFAICT there's no need for those

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

  • <tile> is like a square/rectangular feature, so it is not a child of extent

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
Copy link
Member

Malvoz commented Apr 4, 2022 •
edited
Loading

Looks pretty good. Add:

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):

  • Per the HTML spec, there can only be one <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?
  • Is <title> needed (outside of mapml documents)? We already have <layer label="">.
    I suppose it could be allowed, and label take precedence, as is the case with external mapml documents?

Perhaps it's time to discuss #210?

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?

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-src accordingly?

<tile> is like a square/rectangular feature, so it is not a child of extent

Oops, I've corrected my comment.

@prushforth
Copy link
Member

Per the HTML spec, there can only be one <base> element per document.

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.

Is <title> needed (outside of mapml documents)? We already have .
I suppose it could be allowed, and label take precedence, as is the case with external mapml documents?

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:

If you want to allow only MapML elements here, don't use "metadata content".

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"?

@Malvoz Malvoz mentioned this issue Apr 5, 2022
Open
@prushforth prushforth mentioned this issue Jun 29, 2023
Merged
4 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
3 participants
@zcorpan @prushforth @Malvoz