4 ms·

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 o

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.

nness 6y ago
Magnifying the SVG as part of the workflow, svgo for instance, is a life-saver for all these edge-cases.
- Jestar342 6y ago
  Noted, thanks.
  - mchusma 6y ago
    I use this for most SVGs: https://jakearchibald.github.io/svgomg/ 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".
- city41 6y ago
  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.
SigmundA 6y ago
Just use img tags pointing to SVG's?
- colejohnson66 6y ago
  JavaScript based manipulation of the SVG’s nodes doesn’t work then.
  - SigmundA 6y ago
    But the parent said they switched to PNGs, same issue right?
    - Jestar342 6y 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.
      - SigmundA 6y 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.
        Jestar342 6y 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
        SigmundA 6y ago
jansan 6y ago
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 https://github.com/iconfu/svg-inject

nness 6y ago

Magnifying the SVG as part of the workflow, svgo for instance, is a life-saver for all these edge-cases.

Jestar342 6y ago
Noted, thanks.
- mchusma 6y ago
  I use this for most SVGs: https://jakearchibald.github.io/svgomg/ 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".
city41 6y ago
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.

SigmundA 6y ago

Just use img tags pointing to SVG's?

colejohnson66 6y ago
JavaScript based manipulation of the SVG’s nodes doesn’t work then.
- SigmundA 6y ago
  But the parent said they switched to PNGs, same issue right?
  - Jestar342 6y 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.
    - SigmundA 6y 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.
      - Jestar342 6y 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
        SigmundA 6y ago

jansan 6y ago

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 https://github.com/iconfu/svg-inject