Oh god, cursed idea; storing your SVG UI elements as strings in local storage, that you stuff into the DOM via JS, so that you get the benefit of "caching" like they're an img src, but also the ability to target and style in CSS because they're loaded on the page as actual SVG.
Essentially loading SVG assets you often want to theme with CSS as a browser-stored package. Instead of needing to dump raw SVG in HTML, or do icon-green.svgicon-red.svg etc.
@mattwilcox TIL that you could use the use attribute of svg: instead of an <img> you do <svg><use href="img.svg#my-path" style="--my-prop: ..."></use></svg> and in the svg file you do <path ... style="fill: var(--my-prop, #fff)"/>. It id to the path/group is important or it won't show anything. Would that solve the caching/styling problem for you?
Heck, you could keep the raw source as <img> tags and use the JS to dynamically replace them with the SVG itself.
WAIT THAT IS A BETTER IDEA!
Parse the HTML for <img src="icons/whatever.svg" ... /> and pull the SVG content out (load the referenced src attribute in the JS), then replace the entire image element with the SVG content in the DOM. To which your main CSS stylesheet can now be applied.
@noleli Yeah, I got about 30s into coding an implementation (raw JS, not a component) before I had to do "actual real work"... then I forgot entirely about it!
Your implementation looks neat.
I was just going to use something like const svgSwaps = document.queryselectorAll("img[src$=.svg].svgSwap"); to operate only on items with a class that also had to be svg's (in case of fuck ups), but I think I got about that far before Real Work dropped in.
wrt caching, for me in FF it seems to not be using the same cached resource from the <img> when it does the fetch, so it’s downloading the asset twice. Once it’s been fetched, I think future fetch()s will used the cached version, but it doesn’t seem to use the one from the <img> :(
@noleli That's a little annoying - I thought resource assets never got requested more than once if they were cachable (via their header response). Is it actually grabbing the image before the component initialises? How about if you use loading='lazy' on the img itself so the parser isn't being over-eager (assuming that's the issue)?
@noleli so, i could replace my web site's secret content architecture that currently stashes ciphertext in a <pre> and includes the decrypt form in HTML with
It takes an <img src="my.svg" ... /> element, and it replaces the img with the raw SVG.
Why?
Because caching. Images are cachable, and inline SVG is not. If you have a suite of icons and you want to colour-control them in various places with CSS, you either have to inline them so you can apply CSS (so no caching) or have individual pre-made SVGs as icon-green.svg etc.
Add comment