[Jestar342]

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.

[SigmundA]

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.

[Jestar342]

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