Hacker News new | ask | show | jobs
by Jestar342 1945 days ago
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.
1 comments
SigmundA 1945 days ago
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.

link
Jestar342 1944 days ago
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

link
SigmundA 1944 days ago
Yeah sorry just not getting it, you can't use SVG's with image tags due to not being able to manipulate them however you then go to PNG's which are even harder to manipulate and are img tags right?

At least SVG as images can be resized so you only need one asset regardless of size, color manipulation then is the issue, but since SVG is just xml it pretty easy to do server side and again the browser will handle caching just like any other image.

link
Jestar342 1944 days ago
shrug The switch to PNG was in haste after we suddenly saw our icons etc all using whatever the last loaded SVG looks like. We already have a PNG "solution" (more like a hack.. someone remembered how to use imagemagick to setup up some build time manipulation of the PNGs -- we didn't even check if we could do this for SVGs we just wanted it fixed asap) plus the designers offered to export the bulk of variants as PNGs for us without much discussion at all, and the rest we made up with the imagemagick hack.

So we jumped to PNGs (like 2 weeks ago, fyi). Now that we (know about, and) can use one of the svg cleaners, we'll switch to that and go back to inline SVGs.

PNGs were always seen as inferior. We don't want extra requests to load them - our app is very sensitive to the number of requests we make - we're importing them as datastrings even.

Anyway, the choice was made. Now we're 90% likely to revert to inlining SVGs with some kind of cleaner in the pipeline. Please don't lose any sleep over it. We'll be just fine.

link