SVG Rendering behavior changes needed #368
Comments
|
-- moved from #367 -- Give this test case a try. FWIW I think we can drop the role=region, as it doesn't seem appropriate. We can add spans/links in a second iteration; when geometries have spans in them, there will need to be duplication of paths, and the order matters: the spanned content should come after the base polygon. <!doctype html>
<html lang="en">
<head>
<meta charset="utf-8">
<meta name="viewport" content="width=device-width,initial-scale=1">
<title>index-map.html</title>
<script type="module" src="dist/mapml-viewer.js"></script>
<style>
html,
body {
height: 100%;
}
* {
margin: 0;
padding: 0;
}
/* Specifying the `:defined` selector is recommended to style the map
element, such that styles don't apply when fallback content is in use
(e.g. when scripting is disabled or when custom/built-in elements isn't
supported in the browser). */
mapml-viewer:defined {
/* Responsive map. */
max-width: 100%;
/* Full viewport. */
width: 800px;
height: 600px;
/* Remove default (native-like) border. */
/* border: none; */
}
/* Pre-style to avoid FOUC of inline layer- and fallback content. */
mapml-viewer:not(:defined) > * {
display: none;
}
/* Ensure inline layer content is hidden if custom/built-in elements isn't
supported, or if javascript is disabled. This needs to be defined separately
from the above, because the `:not(:defined)` selector invalidates the entire
declaration in browsers that do not support it. */
layer- {
display: none;
}
</style>
<noscript>
<style>
/* Ensure fallback content (children of the map element) is displayed if
custom/built-in elements is supported but javascript is disabled. */
mapml-viewer:not(:defined) > :not(layer-) {
display: initial;
}
</style>
</noscript>
</head>
<body>
<mapml-viewer projection="OSMTILE" zoom="16" lat="0" lon="0" controls>
<layer- label="LAKES" checked>
<meta name="cs" content="pcrs" >
<meta name="projection" content="OSMTILE" >
<meta name="extent" content="top-left-easting=66.79,top-left-northing=-11.13,bottom-right-easting=345.09,bottom-right-northing=-200.38" >
<style>
.poly {
fill: red;
stroke: pink;
stroke-width: 3px;
}
.multipoly {
fill: blue;
stroke: cyan;
stroke-width: 3px;
}
.geocollection {
fill: green;
stroke: chartreuse;
stroke-width: 3px;
}
</style>
<feature id="polygon.1">
<featurecaption>Polygon Feature</featurecaption>
<geometry>
<polygon class="poly">
<coordinates>66.79169447596414 -200.37508346187343 111.31949079327357 -66.79169447822557 267.16677790385654 -11.131949079964679 345.09042145914805 -166.97923620971676 66.79169447596414 -200.37508346187343</coordinates>
<coordinates>189.24313434856506 -122.45143988021553 278.29872698318394 -122.45143988021553 278.29872698318394 -66.79169447822557 189.24313434856506 -66.79169447822557 189.24313434856506 -122.45143988021553</coordinates>
</polygon>
</geometry>
</feature>
<!-- The above feature should render as:
<g aria-expanded="false" aria-label="Polygon Feature" data-fid="polygon.1" tabindex="0" class="leaflet-interactive poly">
I would not object to there being an intermediate group here, but it's not necessary
if there are spans in the polygon, the markup will require some more paths
<path data-fid="polygon.1" d="M428 384L447 328L512 305L544 370L428 384zM479 351L517 351L517 328L479 328L479 351z"></path>
</g>
-->
<feature id="multipolygon.2">
<featurecaption>MultiPolygon Feature</featurecaption>
<geometry>
<multipolygon>
<polygon class="multipoly">
<coordinates>366.79169447596414 -200.37508346187343 411.31949079327357 -66.79169447822557 567.16677790385654 -11.131949079964679 645.09042145914805 -166.97923620971676 366.79169447596414 -200.37508346187343</coordinates>
<coordinates>489.24313434856506 -122.45143988021553 578.29872698318394 -122.45143988021553 578.29872698318394 -66.79169447822557 489.24313434856506 -66.79169447822557 489.24313434856506 -122.45143988021553</coordinates>
</polygon>
</multipolygon>
</geometry>
</feature>
<!-- The above should render as:
<g aria-expanded="false" aria-label="MultiPolygon Feature" data-fid="multipolygon.2" tabindex="0" class="leaflet-interactive ">
<g class="multipoly"> need a group for each polygon in the multipolygon
if there are spans in the polygon, the markup will require some more paths
<path d="M554 384L572 328L637 305L670 370L554 384M605 351L642 351L642 328L605 328L605 351"></path>
</g>
</g>
-->
<feature id="geometrycollection.3">
<featurecaption>GeometryCollection Feature</featurecaption>
<geometry>
<geometrycollection>
<polygon class="geocollection">
<coordinates>66.79169447596414 -0.37508346187343 111.31949079327357 133.20830552177443 267.16677790385654 188.868050920035321 345.09042145914805 33.02076379028324 66.79169447596414 -0.37508346187343</coordinates>
<coordinates>189.24313434856506 77.54856011978447 278.29872698318394 77.54856011978447 278.29872698318394 133.20830552177443 189.24313434856506 133.20830552177443 189.24313434856506 77.54856011978447</coordinates>
</polygon>
</geometrycollection>
</geometry>
</feature>
<!-- Should render to:
<g aria-expanded="false" aria-label="GeometryCollection Feature" data-fid="geometrycollection.3" tabindex="0" class="leaflet-interactive">
<g class="geocollection"> if there are spans in the polygon, the markup will require some more paths
<path d="M428 300L447 244L512 221L544 286L428 300M479 268L517 268L517 244L479 244L479 268"></path>
</g>
</g>
-->
</layer->
</mapml-viewer>
</body>
</html> |
|
Another test case (this one has a ghost marker): <!doctype html>
<html lang="en">
<head>
<meta charset="utf-8">
<meta name="viewport" content="width=device-width,initial-scale=1">
<title>index-map.html</title>
<script type="module" src="dist/mapml-viewer.js"></script>
<style>
html,
body {
height: 100%;
}
* {
margin: 0;
padding: 0;
}
/* Specifying the `:defined` selector is recommended to style the map
element, such that styles don't apply when fallback content is in use
(e.g. when scripting is disabled or when custom/built-in elements isn't
supported in the browser). */
mapml-viewer:defined {
/* Responsive map. */
max-width: 100%;
/* Full viewport. */
width: 800px;
height: 600px;
/* Remove default (native-like) border. */
/* border: none; */
}
/* Pre-style to avoid FOUC of inline layer- and fallback content. */
mapml-viewer:not(:defined) > * {
display: none;
}
/* Ensure inline layer content is hidden if custom/built-in elements isn't
supported, or if javascript is disabled. This needs to be defined separately
from the above, because the `:not(:defined)` selector invalidates the entire
declaration in browsers that do not support it. */
layer- {
display: none;
}
</style>
<noscript>
<style>
/* Ensure fallback content (children of the map element) is displayed if
custom/built-in elements is supported but javascript is disabled. */
mapml-viewer:not(:defined) > :not(layer-) {
display: initial;
}
</style>
</noscript>
</head>
<body>
<mapml-viewer projection="OSMTILE" zoom="16" lat="0" lon="0" controls>
<layer- label="LAKES" checked>
<meta name="cs" content="pcrs" >
<meta name="projection" content="OSMTILE" >
<meta name="extent" content="top-left-easting=66.79,top-left-northing=-11.13,bottom-right-easting=345.09,bottom-right-northing=-200.38" >
<style>
.poly {
fill: red;
fill-opacity: 1.0;
stroke-width: 3px;
}
.one {
stroke: yellow;
stroke-width: 10px;
fill: none;
}
.two {
stroke: orange;
stroke-width: 5px;
fill: none;
}
.three {
stroke: pink;
stroke-width: 7px;
fill: none;
}
</style>
<feature id="polygon.1">
<featurecaption>Polygon Feature</featurecaption>
<geometry>
<polygon class="poly">
<coordinates><span class="one">66.79169447596414 -200.37508346187343 <span class="two">111.31949079327357 -66.79169447822557 267.16677790385654 -11.131949079964679</span> 345.09042145914805 -166.97923620971676 </span>66.79169447596414 -200.37508346187343</coordinates>
<coordinates><span class="three">189.24313434856506 -122.45143988021553 278.29872698318394 -122.45143988021553</span> 278.29872698318394 -66.79169447822557 189.24313434856506 -66.79169447822557 189.24313434856506 -122.45143988021553</coordinates>
</polygon>
</geometry>
</feature>
<!--
<g aria-expanded="false" aria-label="Polygon Feature" data-fid="polygon.1" tabindex="0" class="leaflet-interactive">
the polygon as marked up should create five path elements:
First, the shadeable polygon, with 10 coordinate pairs
<path class="poly leaflet-interactive" d="M428 384L447 328L512 305L544 370L428 384zM479 351L517 351L517 328L479 328L479 351z"></path>
The next should the "unspanned" coordinates representing the polygon outline, that contains zM subcommands to "skip over" what is to be
the responsibility of spanned coordinates, so I think it should have 6 coordinate pairs (not shown) for the above polygon:
<path class="mapml-feature-outline" d="M...z"></path>
The next paths each represent a span directly, remembering to include or not previous or next points into their d attribute:
one contains four coordinate pairs
<path class="one" d="M...z"></path>
two contains two coordinate pairs
<path class="two" d="M...z"></path>
three contains two coordinate pairs
<path class="three" d="M...z"></path>
</g>
-->
</layer->
</mapml-viewer>
</body>
</html> |
|
I believe this is because <coordinates><span class="one">66.79169447596414 -200.37508346187343 <span class="two">111.31949079327357 -66.79169447822557 267.16677790385654 -11.131949079964679</span> 345.09042145914805 -166.97923620971676 </span>66.79169447596414 -200.37508346187343</coordinates>Specifically ...</span>66.79169447596414 -200.37508346187343</coordinates>This coordinate is standalone/representing of a point, meaning it gets transformed to an svg marker, what are the alternatives? |
|
No, I believe it should be treated as part of the mapml-feature-outline, preceded by a M to the last coordinate in the preceding span, followed by a zM, then the first coordinate in the next |
|
The only time you should render a point is if the |
Doesn't that change what a |
|
Similarly, putting spans in coordinates should allow you to select/style the content appropriate to how you want to do that, but it should still represent the entity. That was the relation between coordinates and paragraphs: needing the ability to target parts of it without changing the meaning of the whole. In any case, the mapml-feature-outline generated does not represent the outline; it contains just that point but not the hole, if my eyes don't deceive me (going a bit coordinate blind at this point). I suggest it should contain a move to the point before that point, despite that it's in a preceding span, then a line to that point, then a move to the start of the hole, then a move to the last point in the span that covers the start of the hole (skipping it because it will be rendered in a subsequent path), then a series of lines to finish the hole, which terminates the mapml-feature-outline. |
Comment changes that are needed for the renderer below.
The text was updated successfully, but these errors were encountered: