[openstreetmap/openstreetmap-website] Can we avoid inlining svgs into erb templates? (Issue #5880)

[Tom Hughes]

tomhughes left a comment (openstreetmap/openstreetmap-website#5880)

I've read through all the comments on this issue and also had a look at @hlfan's work in #5938 and on the whole I think that I have to agree with @gravitystorm and @hlfan that it would better if we could keep the SVGs separate.

I don't actually think that your position on whether SVGs should be hand written or created with a visual editor really alters the position on that - it's just generally easier for everybody if you can at least view what an image looks like in an image viewer or rich diff tool and combining languages in one file always makes life it's just that sometimes the benefits make it worthwhile but I'm not sure that's true here.

Incidentally for a while I was unable to review edits to at least one of our view in `meld` because it would just bomb out and eventually I realised it was because it thought it was an SVG file and was trying to do a visual diff on it so I had to hack meld to disable that.

I think @hlfan's work in #5938 is generally good though I haven't done a detailed review but I think https://github.com/jamesmartin/inline_svg that he mentioned here might offer some advantages and I think a custom transform could do the magenta -> currentColor transformation but by actually parsing the XML instead of doing regexp edits on it which is always risky.

It also provides caching of transformed SVGs and access to the rest of the asset pipeline like `svgo` optimisation.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/openstreetmap/openstreetmap-website/issues/5880#issuecomment-3065647432
You are receiving this because you are subscribed to this thread.

Message ID: <openstreetmap/openstreetmap-website/issues/5880/3065647432 at github.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/rails-dev/attachments/20250712/a5858b10/attachment.htm>