Option to generate unique IDs?

[pluma]

This is a feature request.

There's a plugin for minifying IDs but this is basically useless when inlining SVGs in HTML because it is guaranteed to cause problems (i.e. when inlining at least two SVGs that contain IDs you're guaranteed to have a conflict on ID "a").

It would be very useful if SVGO allowed prefixing IDs with a configurable key. This would allow tooling like react-svg-loader to generate a unique prefix and pass it to SVGO to guarantee the IDs don't break when the SVGs are inlined.

A problem is that the IDs can be referenced with xlink:href attributes and url() values but this is already addressed by the cleanupIDs plugin.

[GreLI]

Actually, cleanupIDs has prefix option (works only with minifying).

[Kraxxis]

I, too, need this feature.

the cleanupIDs prefix option is not a solution to this problem. Consider two svg files both of which have a defined id "id1". When using the two separate svgs inline, these two ids will conflict, since they exist in the same document. Using the prefix option only moves this problem from having two conflicting "id1" ids to having two conflicting "prefix_id1" ids.

[Emasoft]

The prefix should be the name of the file. For example:

IconOfACar.svg -> iconofacar_id1
IconOfABeer.svg -> iconofabeer_id1

[pluma]

Being able to supply the prefix should suffice. Seems more versatile than having SVGO pick one automagically.

[Emasoft]

I don't think that is versatile for batch processing. I usually process thousands of svg files with a script at every site update, and I surely don't want to manually enter a prefix for each one.

[strarsis]

Similar issue?: #673

[OwenMelbz]

Is there any movement on this?

As much as it sounds a dick move, I think you need to go with a general consensus here, this is an issue that many users are having when using inlined SVGs when passed through SVGO - for example we even have this issue using Sketch SVGO Compressor plugin, we end up having 10 SVGs with #a that causes masking issues so have to manually go through the file and change them, which is not feasible for a fully automated system.

As @Emasoft has suggested, I think the only sensible solution would be to slugify the filename and use that as the id prefix, turn this on as a default, which means every user that has an automated workflow or has tools that then use svgo will be unaffected, unless they pass in an extra option to disable it something like --disable-auto-id-prefix

@strarsis this does seem like similar issue yeah, I think the issue as a whole is just around "naming conflicts as the minification process has no concept of other files"

[strarsis]

PR for a plugin that does this - a bit tweaking is necessary though: #700

[GreLI]

@OwenMelbz you can disable minifying IDs in cleanupIDs with the following config:

plugins:
  - cleanupIDs:
      minify: false

So your files will have unique IDs as long as they had it already.

Editing a bunch of files has nothing with optimization, so it lays out of SVGO's scope.

[OwenMelbz]

@GreLI You've completely missed the point - which clearly several other people have agreed there is an issue.

Many automated systems rely on svgo
Many of these systems do not allow the user to modify settings.

e.g Sketch has a official plugin, SVGO Compressor, which uses svgo.
The end user cannot modify the plugin or config.
Thus your reply is void.

Its extremely narrow minded and selfish to disregard an issue simply because you don't want to address it, rather than helping the global community come up with a solution to a community acknowledged issue.

Maybe if we state the problem again you will understand.

---

SVGO when cleaning up IDs (a feature that is still desired) does not have a concept of "other svgs" - which means if you minified 100 svgs, they would all end up having the id of a which means they're next to useless to be embedded into webpages.

The solution to help developers/designers/content writers/PEOPLE is by using the privileged stance of svgos positioning in the development world to implement a feature that solves this issue for users who are using their system for some reason. And there have been plenty of suggestions on ways to solve this.

Remember when Facebook - a social media platform, decided to use its privileged position to help family members involved in world crises to mark theirselves as safe? Yes its not directly their problem to solve, but they could propose a solution because it was for the benefit of its users.

This is why people come to you guys seeking solutions, because you're in a position to help out. Similarly to the cheesy line from spider-man - with great power comes great responsibility.

Maybe thinking of it in a different non-dismissive Trump-like manor will urge you not to slap a "closed" on a real life issue.

[GreLI]

Many of these systems do not allow the user to modify settings.

Unfortunately, nobody here can't fix their obvious flaws. What if different users want totally opposite? Configuration is what makes SVGO flexible. Ask these systems authors to add an option to set a configuration. They get paid for this, unlike me or other OSS maintainers.

The “consensus“ here has been set just in your mind. No statistics or clear numbers has been provided to verify your claims. So please stop your nonsense word pouring. Nobody here has to do something for you. Don't make me block conversation.

[OwenMelbz]

if your gonna act like an arrogant cunt and not help the community out then block it. 👌🏼 Peace out dickhead

[GreLI]

As you wish.