Svgo: If SVG is made larger, even when desirable (eg prefixIds), plugins are not applied

[tremby]

I had particular SVGs not being changed by SVGO, and couldn't figure out why for a long time. This was driving me nuts, but I think I've finally figured it out.

I'm using the prefixIds plugin, because I have a lot of inline SVGs on the same page, and I need to address specific elements to animate them.

If the SVG was already near-optimized such that prefixing the IDs actually makes the SVG data larger even after the other plugins have run, is SVGO discarding the changes?

Of course this would make sense if every plugin's only goal was to make the SVG smaller, but that isn't the case.

This may be the cause of a few issues in the tracker, including #985 and #943.

If I'm right about the above, I'm wondering about possible solutions. Perhaps some plugins need to hint that their output must be kept even if the file gets bigger?

[missmatsuko]

I wanted to use the addAttributesToSVGElement plugin to add aria-role='presentation' to all of my SVGs, but it's only applying to about half of them. Thinking this is related.

If that's the case, this is a pretty bad bug. It means the plugins don't reliably do what they're supposed to, especially the ones that are supposed to add code.

[tremby]

OK, so this affects at least:

• prefixIds
• cleanupIDs (especially with prefix option)
• addAttributesToSVGElement
• addClassesToSVGElement

[missmatsuko]

Not tested, but it might also affect convertStyleToAttrs.
It may be desirable in some cases to convert styles to attributes, even if it increases the file size of an SVG, to avoid style conflicts from different SVGs on a page having styles with the same selectors.

[tremby]

I did some digging. The bit of code I referenced above was a red herring -- that just stops the multipass loop (not discarding the latest iteration) if the latest iteration was no smaller than the previous. There may be some edge cases where this causes a problem? Unsure about that.

But I traced the dependency chain through several packages until I found that the real problem at least in my case is in imagemin-webpack-plugin. This package, in its optimizeImage function, is discarding output if it isn't smaller. It seems to me this shouldn't be that package's concern.

I will post a bug against that and link to it here.

[tremby]

I proposed a patch to imagemin-webpack-plugin: https://github.com/Klathmon/imagemin-webpack-plugin/pull/89