-
-
Notifications
You must be signed in to change notification settings - Fork 1.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
prefixIds breaks references between defs + use #913
Comments
@CH-RhyMoore: Apparently the |
@strarsis Given that the order of plugins in the configuration matters, but that there is no explicit documentation of the correct order, I have been patterning my order off of files in the repo, like this: https://github.com/svg/svgo/blob/master/.svgo.yml#L30-L32 Perhaps the order in the README is preferable? If so, where should |
@strarsis To test, I moved it down to the bottom and while the <svg xmlns:xlink="http://www.w3.org/1999/xlink" width="24" height="24" viewBox="0 0 24 24" pointer-events="none">
<defs>
<path id="svg400__a" d="M10.5 16.584L4.32 20l1.18-7.236-5-5.125 6.91-1.055L10.5 0l3.09 6.584 6.91 1.055-5 5.125L16.68 20z"/>
</defs>
<g fill="currentColor" fill-rule="evenodd" transform="translate(1.5 2)">
<use fill-rule="nonzero" xlink:href="#svg402__a"/>
<path d="M-1.5-2h24v24h-24z"/>
</g>
</svg> This results in the following visual: I observed that the
|
There's another glitch in the original export that is coming from a technique used in Sketch, so while I still have visually broken SVGs, it's no longer due to the ID issues. I didn't really need to move Unfortunately, what's passed to the
function optimize ({ contents, path }) {
return svgo.optimize(contents, path);
} const hash = require('string-hash');
...
prefixIds: {
prefix: function (element, filepath) {
return `svg${hash(filepath)}`;
}
} <svg xmlns:xlink="http://www.w3.org/1999/xlink" width="24" height="24" viewBox="0 0 24 24" pointer-events="none">
<defs>
<path id="svg461883165__a" d="M10.5 16.584L4.32 20l1.18-7.236-5-5.125 6.91-1.055L10.5 0l3.09 6.584 6.91 1.055-5 5.125L16.68 20z"/>
</defs>
<g fill="currentColor" fill-rule="evenodd" transform="translate(1.5 2)">
<use fill-rule="nonzero" xlink:href="#svg461883165__a"/>
<path d="M-1.5-2h24v24h-24z"/>
</g>
</svg> This keeps the references between |
@CH-RhyMoore: Would you recommend extra parameters to be passed to |
@strarsis I think so, yes. If it's possible. The reason I think it'd be a good idea is that, from the issues, I got the impression one of the use cases you wrote it for is being able to get unique IDs that don't collide between files. But the first few obvious choices for using it (some of which in my case were inspired by tests/issues discussion/the PR) can lead a user in the wrong direction. For that use case, a user doesn't want to make IDs that are supposed to be the same in the same file different from each other, but it's not immediately obvious that that needs extra attention when you are customizing it. Once you follow all the bread crumbs, it's not hard code to write, but it did take a while to find some of the crumbs. I assume that challenge of correlating IDs between elements comes from how the plugins run in general, not from this specific plugin. |
@strarsis One specific idea that could help is passing the default prefix in. You derive that from the filename, so whether someone wants to customize on top of the filename, do something like I did, or needs to do something really unusual, it'll provide the context essential to keeping references intact. |
@CH-RhyMoore: Currently the var filename = path.basename(extra.path);
prefix = filename; For prefixing the filename by passing a custom prefixIds: {
prefix: function (element, extra) {
var filename = path.basename(extra.path);
...
return filename + prefix;
}
} Concerning an improved option feature for configuring hashes used by the {
...
prefixIds: {
hash: {
prefix: "some prefix-",
suffix: "-some suffix"
}
},
...
} And for the current behaviour (just always using the same prefix): {
...
prefixIds: {
hash: "use always this hash"
},
...
} Preserving the ability to pass a callback function for generating the hash: {
...
prefixIds: {
hash: function(node, extra){...}
},
...
} Then there is the |
A first good step is proposed in my PR #907 and it lets you use it like this:
or like this
|
@vzaidman: And for using the input file name for the prefix? |
for now it works like what you wrote isn't it? |
maybe we should add a plugin by the name "transformId" instead of "prefixId" (deprecate it) and let the user transform the Id to whatever he likes:
|
If anyone is looking to generate unique ID while using svg-react-loader, I have a fix here : https://github.com/SilverFox70/svg-react-loader |
Version: [email protected]
I have been trying to get SVGO to output unique IDs for elements in a batch of SVGs. I have several SVGs in my iconset that end up visually broken due to colliding IDs.
I thought I finally had a solution when I found the undocumented
prefixIds
plugin, but when I useprefixIds
, it ends up stripping out the<defs>
entirely, which just results in SVGs that are still visually broken, only now for a different reason. I am guessing thatprefixIds
doesn't make the two IDs match up correctly between these two elements, so whenremoveUselessDefs
runs, it gets removed.This isn't my only problem with the output, although it is the most important as it is blocking my progress. Another noteworthy thing about
prefixIds
's behavior is I had to (at one point, though perhaps not anymore) enablemultipass
to get all the optimizations, but withmultipass
,prefixIds
is prefixing twice, which is really an un-optimization.Related: #595, #674, #766, #834
Example Input SVG:
Example Output SVG without
prefixIds
:Example Output SVG with
prefixIds
and multipass:Example Output SVG with
prefixIds
and single pass:Configuration:
The text was updated successfully, but these errors were encountered: