Introduced and missed in #17
So, vitejs/vite#14643 made it so that inlined SVGs are not base64 encoded when possible (sensible move, seems to save on space).
However, when ArcGIS is passed an inlined asset, in this file for example,
|
defaultSymbol: {type: 'picture-marker', url: squareParkingIcon, width: 12, height: 12}, |
it has some logic hardcoded that says "oh that's an SVG? cool I'm gonna rewrite that metadata myself, including a
base64 marker". Meaning all of the non-encoded icons are marked as encoded and the browser can't load them.
The real solution would be for ArcGIS to... not do that. But I wouldn't hold my breath. I also don't see a "force base64" option for svgs in vite, so I'm thinking that the only practical solution is to forego inlining altogether (ugh).
The "when possible" mentioned earlier is actually "when there's no <text> element in the SVG", which is why the MA icon is still encoded and still works.
Introduced and missed in #17
So, vitejs/vite#14643 made it so that inlined SVGs are not base64 encoded when possible (sensible move, seems to save on space).
However, when ArcGIS is passed an inlined asset, in this file for example,
parking-map/src/layers/spaces.js
Line 42 in 5a07d33
it has some logic hardcoded that says "oh that's an SVG? cool I'm gonna rewrite that metadata myself, including a
base64marker". Meaning all of the non-encoded icons are marked as encoded and the browser can't load them.The real solution would be for ArcGIS to... not do that. But I wouldn't hold my breath. I also don't see a "force base64" option for svgs in vite, so I'm thinking that the only practical solution is to forego inlining altogether (ugh).
The "when possible" mentioned earlier is actually "when there's no
<text>element in the SVG", which is why theMAicon is still encoded and still works.