Hacker News new | ask | show | jobs
by Jestar342 1955 days ago
Recently switched from SVGs to PNGs because the toolset the designers are using means every SVG has the same HTML ID attribute value. So when rendering >1 SVG on a page, they all render the same as the last one in the dom.
3 comments

Take a look at SVG Injection. This may solve your problems, as the injector will add a unique id to your SVG:

https://github.com/iconfu/svg-inject

Magnifying the SVG as part of the workflow, svgo for instance, is a life-saver for all these edge-cases.
Especially considering the svg that a design tool produces is often gigantic. FWIW I have found svgcleaner to be better than svgo. svgo seems to have more bugs and chokes on svgs more often in my experience.
Noted, thanks.
I use this for most SVGs: https://jakearchibald.github.io/svgomg/

"SVGO's Missing GUI". Give it to the designers and they can make sure to give you the smallest possible file that makes sense. I find that some files look great at "0" precision, some require "1" or "2".

Just use img tags pointing to SVG's?
JavaScript based manipulation of the SVG’s nodes doesn’t work then.
But the parent said they switched to PNGs, same issue right?
I decided to switch from SVG with build time manipulation of attributes (scale, colours, rotation, etc) to an image optimisation library (and soon probably a saas like imgix).

I'd prefer to have stuck with SVG had it not been for the I'd collision thing, so with one of these tools in our chain we just might do that.

IMG tags pointing to SVG's don't have ID collsions since the SVG is in a isolated context, it's opaque to the referencing page because it's treated like any other img reference.

We use some server side code to recolor svg's on the fly with caching headers so they aren't requested all the time, mostly through img tags since we moved from PNG to SVG, its just works.

It's a no-go for this use case. Simply because we cannot manipulate the SVG's attributes (at least not as easily) when using them within img tags. Can when they are "inlined". We reluctantly adopted PNGs and convinced designers to provided assets for a whole spread of sizes and colours which doubled or even trippled their workload, just because we were stalling and trying to find alternatives (we have begun building an automation chain for PNG colour conversion etc). Moving forward, I'm going to experiment with one/some of the SVG optimisers and try going back to build/run-time SVG attribute manipulation. It's what SVGs were built for.

Using inline SVGs also reduces our caching complexity _dramatically_. I'm now "just" caching markup with no binary asset caching.

Moving forward I'm going to experiment with