SVG should not transform translate
Exporting vector graphic shouldn't transform translate at all!
When exporting e.g. icon why there is "data-name" and transform="translate"? Svg's are very often animated, or changed on hover. Sometimes element inside might be moving and translate is perfect for moving path where you cant change x and y. I understand maybe its faster for adobe xd to calculate translate when moving element but at least on export paths should be recalculated to have NONE of translate's. I'm not even sure if we can call it a feature, its more like bug that produces totally unnecessary attributes. When exporting, file should be as clean as possible, no data-name, no id, no translate.
Also very often when exporting element container has like transform=translate(-1700,-1200) and inside groups have transform=translate(-1701.345,-1204.123).
Piotr Wysocki
shared this idea
5 comments
-
Christoph Mauerhofer
commented
I have this problem too. I have icons which consist of a group of one path and one transparent rectangle (square) shape in the background, so that all icons keep their square 24x24 pixels dimensions after exporting. I have multiple of these icons on one artboard (as part of a mockup) and I want to export them as SVG assets.
If e.g. an icon is placed on pixel position 50, 75 on the artboard, in the exported SVG the path and the rect elements would receive a transform: translate(50, 75) property and then the group around both elements would have a transform: translate(-50, -75) property. Of course these two cancel each other out so that the path and rect are really placed at position (0, 0) inside the exported SVG. But the two transforms are therefore redundant and should really all be removed. -
Thomas Deinhamer
commented
As a developer I want to have SVG files as small and cleaned up as possible. Superfluous transforms make it impossible to work with the SVG in development (adding animations, etc.). Also the transforms bloat the SVG size unnecessarily.
There should absolutely be an export option to remove transforms (and recalculate path coordinates based on the transforms) so the exported files are as optimized and clean and small as possible.
PS: This is a BIG deal for web development.
These are related:
* https://adobexd.uservoice.com/forums/353007-adobe-xd-feature-requests/suggestions/32042245-export-svg-with-artboard-boundary-without-transfo
* https://adobexd.uservoice.com/forums/353007-adobe-xd-feature-requests/suggestions/15616317-save-svg-icons-without-transform-at-root-level -
Saransh Vashistha
commented
Yes, It's painful as if I use CSS keyframe with translate property to animate the group then the animation doesn't behave as expected since inline CSS is prioritized over external CSS and the group animates but its position gets shifted to some other part of the viewport. There should be an option Like INKSPACE has to flatten transforms and calculate and update the path of the elements in the group so that it doesn't require translate property. I'm sure so many developers use INKSPACE as it provides more such features. PLease add this feature as soon as possible.
-
HP Stern
commented
We have the same issue, and would love to see this updated.
My company Kaon interactive, like many companies, uses SVGs for dynamic icon animation. We have recently run into an issue using icons directly from XD as they add a transform="translate" properties to every object. We are wondering if there might be a way for the Adobe dev teams to update the export featuer of the application to make this an option to be turned on or off. We run into a lot of challenges when working with these being automatically placed on all objects. We often find ourselves using the same object in many scenarios and it makes updating those objects very time consuming.
Below is a note from our lead developer as to our challenge.
Thank you for your time.
H.P. Stern
Hi
Transforms can be used to position, rotate, or scale an element.
Position and size could also be done with a handful of other mechanisms.
Transforms a special because the browser puts them on their own layer, it separates each transformed element from the rest of the page.
Browsers use a computer's GPU to render transformed layers, instead of the CPU that it runs javascript and the rest of the layout on.
Rendering on the GPU has pros and cons.
The pro is that the GPU can render a layer at 60 FPS regardless of what the CPU is doing. That means that you'll get the smoothest animation.
The con is that GPU typically has a small amount of memory compared to the main CPU. If the transformed element isn't going to move, it won't benefit from the FPS, and will just take up memory.
At Kaon, we use translation in animation.
We expect the natural position of an element to be determined by another mechanism, like top and left, or the natural page flow.
For example, let's say we want an animation to slide a few elements to the right and scale it up.
If those elements are naturally positioned using "left", they might look like this:
.exampleElement1 {
left:30px;
}
.exampleElement2 {
left:80px;
}
Here, we can write a class that we want to apply to all such elements. This says an element's natural transform should have 0 translation and a scale of 1, and if the transform changes, it should animate to the new value over 0.5 seconds:
https://pastebin.com/6VutSN7T -
Rinor Sadiku
commented
That is so true, and it really is a big pain in the rear.
That sole "bug" per-se, made me really consider switching to figma as a design tool, which i did temporarily to export some assets which a had to redo again :\