Links (and spans) in <geometry> content #367

prushforth · 2021-03-23T20:02:54Z

An odd way to write a spec, but here are a few ideas, for discussion. Please comment @shepazu and @Malvoz !

<mapml lang="en" xmlns="http://www.w3.org/1999/xhtml/">
    <head>
        <meta charset="UTF-8" />
        <title>BasicPolygons</title>
        <meta content="text/mapml" http-equiv="Content-Type" />
        <meta name="extent" content="top-left-longitude=-2.000000,top-left-latitude=6.000000,bottom-right-longitude=2.000000,bottom-right-latitude=-1.000000" />
        <meta name="cs" content="gcrs" />
        <meta name="projection" content="MapML:EPSG:4326" />
    </head>
    <body>
        <!-- links here would make no sense -->
        <feature id="BasicPolygons.1" class="BasicPolygons">
        <!-- links here would make no sense -->
        <geometry>
            
        <!-- links here would be drawn around the entire geometry. Each polygon in a multipolygon would
                be interactive; same for any other geometry type. The holes in polygons would be non-interactive; 
                if there was another feature in
               the hole (an island, say), the island could itself be wrapped in a link, so we would want the
               island's link's behaviour to take over. A span here might not be too useful, but would not be
            harmful, I think; you already have the root geometry element to hang attributes on (e.g. class, and so on).
        FWIW I believe that some markup is not supposed to be found in the content of <a> (see Permitted Content): 
            https://developer.mozilla.org/en-US/docs/Web/HTML/Element/a#properties -->

            <!-- Regarding behaviour of links, I think we should use the existing "target" attribute vocabulary:
            https://developer.mozilla.org/en-US/docs/Web/HTML/Element/a#attr-target
            and interpret that value as follows for maps:
        
            IFF the linked resource mime type is text/mapml:

                _self: replace the current layer (i.e. replace the current map layer; same behaviour as named style links) (Default)
                _blank: usually, add a new layer on top of map, but users can configure browsers to open a new window instead.
                _parent: replace all layers in the map with the linked layer. If no other layers, behaves as _self.
                _top: the topmost browsing context (the page) should navigate to the map resource, synthesize an HTML document
                around it, and load the map resource into the synthesized map and process any URL fragments to control the
                initial location of the map view. If no fragment, set zoom to lowest value, centered on extent of map doc.
                (the "highest" context that’s an ancestor of the current one). 
                If no ancestors, behaves as _self.  

            ELSE 
                do what browsers do with similarly tagged links of today's Web.



        -->
            
            <a href="https://example.org">
                <span class="harmlessButNotUseful">
                <multipolygon>
                    <!-- a link here would be drawn around the the entity or entities which it wrapped.  Say there were
                    three polygons in this multipolygon; a link could wrap two of the three. Similarly,
                    say you wanted to style two of the three in a different way than the third. You should
                    be able to wrap selected ones in a <span class="twoOfThreeStyle"> - that would 
                    prevent you from having to put duplicate spans to get the styles you want. -->

                    <polygon>
                        <!-- links in coordinates would be processed like spans are, except that
                        on output they are styled and behave as links.  Same deal, just copy them and
                    their attributes to the appropriate output. -->
                        <coordinates>-1.0 0.0 <a href="./door">0.0 1.0 1.0 0.0</a> 0.0 -1.0 -1.0 0.0</coordinates>
                    </polygon>
                </multipolygon>
              </span>
            </a>
            </geometry>
            <properties>
                <table>
                    <thead>
                        <tr>
                            <th role="columnheader" scope="col">Property name</th>
                            <th role="columnheader" scope="col">Property value</th>
                        </tr>
                    </thead>
                    <tbody>
                        <tr>
                            <th scope="row">ID</th>
                            <td itemprop="ID" />
                        </tr>
                    </tbody>
                </table>
            </properties>
        </feature>
    </body>
</mapml>

ahmadayubi · 2021-03-23T20:30:54Z

So if a feature is a link then the popup is no longer useful in those cases as clicking on the feature now 'goes to' the link instead of opening a popup?

prushforth · 2021-03-23T20:37:40Z

I guess that's true, but putting a link over any text in a browser takes priority over other behaviour you might give it.

ahmadayubi · 2021-03-23T20:42:17Z

I guess that's true, but putting a link over any text in a browser takes priority over other behaviour you might give it.

Yeah that seems reasonable, just confirming the interaction.

prushforth · 2021-03-24T02:32:38Z

I think it might be reasonable to specify the input AND the output here, as I believe you suggested, @ahmadayubi. For example a polygon with a hole:

<polygon>
    <coordinates>6.0E-4 -0.0018 0.001 -6.0E-4 0.0024 -1.0E-4 0.0031 -0.0015 6.0E-4 -0.0018</coordinates>
    <coordinates>0.0017 -0.0011 0.0025 -0.0011 0.0025 -6.0E-4 0.0017 -6.0E-4 0.0017 -0.0011</coordinates>
</polygon>

would normally only need to generate a single to stroke and fill the polygon: e.g.

<g id="polygon">
  <path d="M 35 -10 L 45 -45 15 -40 10 -20 Z M 20 -30 L 35 -35 30 -20 Z" fill="..." stroke="..." fill-rule="nonzero" />
 </g>

Aside: I believe OGC Simple Features polygons should always be filled with the fill-rule of "nonzero" (that's one of the reasons they're "simple", I believe).

However, if there was a span in or around one of the rings, as you find with tile boundaries, you might want to generate separate <path>s appropriate to the situation, which I'll work on tomorrow.

ahmadayubi · 2021-03-24T13:03:22Z

However, if there was a span in or around one of the rings, as you find with tile boundaries, you might want to generate separate s appropriate to the situation, which I'll work on tomorrow.

It already does that I believe.

ahmadayubi · 2021-03-24T13:16:45Z

I believe OGC Simple Features polygons should always be filled with the fill-rule of "nonzero" (that's one of the reasons they're "simple", I believe).

Interesting that simple features specifies an SVG full rule. How does nonzero affect rendering compared to leaflets use of evenodd in terms of visual output @prushforth?

Malvoz · 2021-03-24T13:32:51Z

IFF the linked resource mime type is text/mapml:

                _self: replace the current layer (i.e. replace the current map layer; same behaviour as named style links) (Default)
                _blank: usually, add a new layer on top of map, but users can configure browsers to open a new window instead.
                _parent: replace all layers in the map with the linked layer. If no other layers, behaves as _self.
                _top: the topmost browsing context (the page) should navigate to the map resource, synthesize an HTML document
                around it, and load the map resource into the synthesized map and process any URL fragments to control the
                initial location of the map view. If no fragment, set zoom to lowest value, centered on extent of map doc.
                (the "highest" context that’s an ancestor of the current one). 
                If no ancestors, behaves as _self.

I believe this suggests that each layer is a browsing context container (which may be a prerequisite to enable the sandboxing model as suggested by Amelia in Maps4HTML/MapML-Specification#22 (comment)), but that's not defined for the layer element in the spec.

<coordinates>-1.0 0.0 <a href="./door">0.0 1.0 1.0 0.0</a> 0.0 -1.0 -1.0 0.0</coordinates>

Is the author supposed to give that link an accessible name? Otherwise it is "0.0 1.0 1.0 0.0". I think coordinates not being attribute values (which was questioned by Simon Pieters and answered by Peter in Maps4HTML/MapML-Specification#70) can generally be problematic for assistive technology (any AT that does not understand MapML would announce all contents of <coordinates>, so that's at least an issue in regards to backwards compatibility).

Malvoz · 2021-03-24T13:35:13Z

FWIW the related UCR Capability of this issue is https://maps4html.org/HTML-Map-Element-UseCases-Requirements/#capability-hyperlinks (yet to be discussed).

prushforth · 2021-03-24T13:43:13Z

I believe this suggests that each layer is a browsing context container

I think so, and I think that's appropriate, to be discussed.

Is the author supposed to give that link an accessible name? Otherwise it is "0.0 1.0 1.0 0.0".

Good point, I guess the accessible value of a similar link in human-readable text would be the text content of the link. So yes the author would have to give it an accessible name, but I think a screen reader could say something like "Line of length (whatever)" or something like that instead of reading out the coordinate.

Backwards compatibility is worth more discussion!

prushforth · 2021-03-24T13:59:57Z

Thanks to @Malvoz, who remembered that this feature is under consideration as a UCR. There has not been much discussion over there, but we'll hold polyfill-specific discussion here.

prushforth assigned ahmadayubi Mar 23, 2021

This comment has been minimized.

Sign in to view

prushforth mentioned this issue Mar 24, 2021

SVG Rendering behavior changes needed #368

Closed

ahmadayubi mentioned this issue Mar 26, 2021

Adds ability to wrap geometry subtypes with span and a elements + a element functionality within coordinates #371

Closed

4 tasks

ahmadayubi mentioned this issue Apr 7, 2021

Adds ability to wrap geometry subtypes with span and a elements + a element functionality within coordinates #383

Merged

4 tasks

prushforth closed this as completed in #383 Apr 8, 2021

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Links (and spans) in <geometry> content #367

Links (and spans) in <geometry> content #367

prushforth commented Mar 23, 2021

ahmadayubi commented Mar 23, 2021

prushforth commented Mar 23, 2021

ahmadayubi commented Mar 23, 2021

prushforth commented Mar 24, 2021

ahmadayubi commented Mar 24, 2021

ahmadayubi commented Mar 24, 2021

This comment has been minimized.

Malvoz commented Mar 24, 2021

Malvoz commented Mar 24, 2021

prushforth commented Mar 24, 2021

prushforth commented Mar 24, 2021

Links (and spans) in <geometry> content #367

Links (and spans) in <geometry> content #367

Comments

prushforth commented Mar 23, 2021

ahmadayubi commented Mar 23, 2021

prushforth commented Mar 23, 2021

ahmadayubi commented Mar 23, 2021

prushforth commented Mar 24, 2021

ahmadayubi commented Mar 24, 2021

ahmadayubi commented Mar 24, 2021

This comment has been minimized.

Malvoz commented Mar 24, 2021

Malvoz commented Mar 24, 2021

prushforth commented Mar 24, 2021

prushforth commented Mar 24, 2021