fix(svgo): enable prefixIds by default

[ilteoood]

Hello guys,
with this PR I would like to activate by default the prefixIds plugin of svgo.

It is useful to avoid any kind of id collision that could happen when are defined different linearGradient for multiple svgs in the same page.

[netlify]

✅ [V2]

Built without sensitive environment variables

Name	Link
🔨 Latest commit	20bf243
🔍 Latest deploy log	https://app.netlify.com/sites/docusaurus-2/deploys/634196c8d656bd0008a78aba
😎 Deploy Preview	https://deploy-preview-8191--docusaurus-2.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify site settings.

[github-actions]

⚡️ Lighthouse report for the deploy preview of this PR

URL	Performance	Accessibility	Best Practices	SEO	PWA	Report
/	🔴 27	🟢 98	🟢 100	🟢 100	🟠 80	Report
/docs/installation	🟠 73	🟢 100	🟢 100	🟢 100	🟢 90	Report

[slorber]

Hi

https://github.com/svg/svgo

prefix IDs and classes with the SVG filename or an arbitrary string

Sorry but enabling prefixIds by default is a breaking change that could break the existing CSS selectors of multiple sites. Even if we merge this in a major release, this is likely to annoy many users when upgrading, while it has only be asked by you so far.

Instead of enabling such a thing by default, I'm more likely to accept a PR that allows you to more easily customize the SVGO config: this way you can enable prefixIds yourself and others don't have to change their code.

[ilteoood]

Hi @slorber,
Thank you so much for your review.
The scenario that you are describing sounds a little bit forced.

As svgo changes the ID of each svg file based on usage order, it means that the selector is based on an ephemeral value, which is not the best choise IMO.

What I'm trying to introduce here is a fix for a bug that should not require additional settings: when different svgs files define different gradients, the gradients ID should not overlap as is doing now, mixing color definitions.

Maybe in a major, but IMO this should not be fixed with an external configuration.

[slorber]

If this is a reasonable default to have in SVGO, then you'd rather convince the SVGO team to enable this by default. If you can, then we'll have this after upgrading and releasing the next SVGO major version.

They probably don't want to enable this by default for the same reason as me.

Some users add hardcoded ids to svgs on purpose, and they don't want those ids to change magically by default, this would be a very confusing default behavior

[ilteoood]

But the hard-coded ids are anyway processed by svgo, which substitute them with "a", "b"...
There is not any predictable ID.

The reason why svgo avoid to enable it by default is that it creates much longer ID than necessary. So, they avoid it until someome needs it.

Btw, fine.