Transform translate applied twice, once in pixels, once in percentage
machineloop opened this issue · 5 comments
First and foremost, thanks for this tool. It is extremely impressive, and has made playing with CSS animations fun! Huge thanks!
I wouldn't claim to be an expert here, so this could be by design. Why are there two translates applied in the transform, one with pixels as units and the other with percentages as units?
I was struggling to figure out why my animations were different between Chrome and Firefox. I believe FF is ignoring the second translate, while Chrome applies both. When I remove the second percentage-based definition, both browsers behave similarly. If this is a bug, I hope this helps; if not, I'd love to know what's going on...
Thanks again!
Example CSS Ouput: (translates emphasized)
.S {
-webkit-animation-name: S-transform-keyframes;
-webkit-animation-duration: 5000ms;
-webkit-animation-delay: 0ms;
-webkit-animation-fill-mode: forwards;
-webkit-animation-timing-function: linear;
-webkit-animation-iteration-count: infinite;
-webkit-transform-origin: 0 0;
animation-name: S-transform-keyframes;
animation-duration: 5000ms;
animation-delay: 0ms;
animation-fill-mode: forwards;
animation-timing-function: linear;
animation-iteration-count: infinite;
transform-origin: 0 0;
}
@-webkit-keyframes S-transform-keyframes {
0% {-webkit-transform:translate(0px, 0px) scale(1) rotateX(0deg) rotateY(0deg) rotateZ(0deg) translate(-50%, -50%);-webkit-animation-timing-function: cubic-bezier(.25,.25,.75,.75);}
40% {-webkit-transform:translate(2px, -14px) scale(1) rotateX(0deg) rotateY(0deg) rotateZ(0deg) translate(-50%, -50%);-webkit-animation-timing-function: cubic-bezier(.25,.25,.75,.75);}
60% {-webkit-transform:translate(-9px, -14px) scale(1) rotateX(0deg) rotateY(0deg) rotateZ(0deg) translate(-50%, -50%);-webkit-animation-timing-function: cubic-bezier(.25,.25,.75,.75);}
80% {-webkit-transform:translate(-17px, -6px) scale(1) rotateX(0deg) rotateY(0deg) rotateZ(0deg) translate(-50%, -50%);-webkit-animation-timing-function: cubic-bezier(.25,.25,.75,.75);}
100% {-webkit-transform:translate(-1px, -1px) scale(1) rotateX(0deg) rotateY(39deg) rotateZ(0deg) translate(-50%, -50%);}
}
@Keyframes S-transform-keyframes {
0% {transform:translate(0px, 0px) scale(1) rotateX(0deg) rotateY(0deg) rotateZ(0deg) translate(-50%, -50%);animation-timing-function: cubic-bezier(.25,.25,.75,.75);}
40% {transform:translate(2px, -14px) scale(1) rotateX(0deg) rotateY(0deg) rotateZ(0deg) translate(-50%, -50%);animation-timing-function: cubic-bezier(.25,.25,.75,.75);}
60% {transform:translate(-9px, -14px) scale(1) rotateX(0deg) rotateY(0deg) rotateZ(0deg) translate(-50%, -50%);animation-timing-function: cubic-bezier(.25,.25,.75,.75);}
80% {transform:translate(-17px, -6px) scale(1) rotateX(0deg) rotateY(0deg) rotateZ(0deg) translate(-50%, -50%);animation-timing-function: cubic-bezier(.25,.25,.75,.75);}
100% {transform:translate(-1px, -1px) scale(1) rotateX(0deg) rotateY(39deg) rotateZ(0deg) translate(-50%, -50%);}
}
Thanks for the issue report @jabbrass, and I'm glad you like Stylie! The second, percentage-based translate is intentional. it is necessary for centering content with only transforms. The CSS spec allows for multiple translates in a transform rule, and Rekapi (the engine that generates the CSS animation code) adds it when the "Center to path" option is enabled in the "Motion" tab. In Stylie's case, the first rule specifies which XY coordinates to place a given keyframe, and the second one centers the element. In my testing, this seems to work consistently in both Firefox and Chrome: http://codepen.io/jeremyckahn/pen/KCheJ
If you deselect "Center to path," the centering translate rule will be removed from the generated CSS.
I have adapted your provided CSS for both WebKit and Firefox and do not see a discrepancy: http://codepen.io/jeremyckahn/pen/tAaJH
It sounds like you found a scenario that exposes a potential bug for Firefox. Can you provide an example animation with both the CSS and HTML that exposes the bug? I suspect that there may be other styles related to the layout of the animating element that may be at play.
Thanks for the quick response. I didn't know there was a 'Center to path' option that could be turned off.
Sorry, I neglected to mention any details about what I'm using the animations on. I'm using them to animate paths inside of an SVG. I believe you're right, there must be a bug in the CSS implementation in FF use of SVGs. I've run across other bugs while experimenting, so its not entirely surprising.
I believe that everything works great for regular DOM elements, I tested it both inside and outside the SVG, and only the SVG seems to be a problem on Firefox (32.0.2). Obviously SVG CSS animations are a bit experimental at his point.
Codepens showing difference:
Broken in FF: http://codepen.io/anon/pen/kJmuf
Consisent across Chrome and FF: http://codepen.io/anon/pen/rkFqd
Thanks for the samples. Both links actually work inconsistently for me in Firefox and Chrome — can you please check the second CodePen link again?
As far as SVG animation and CSS, my knowledge is fairly limited. If there is a general, non-invasive rule that can be applied to Rekapi/Stylie's generated CSS to make SVG animations work more consistently across more browsers, I would be happy to add it by default. In your experimentation, have you found a rule that will achieve this?
Yes, sorry, I pasted the wrong link in the second example, I just modified it above to: http://codepen.io/anon/pen/rkFqd
The first link has different initial animation positioning, the second, one corrected here, should be positioned the same in both browsers without the second translate.
I don't know of any general, non-invasive rule; I suspect that you're correct in your assessment that there's a FF bug at work here. I'm ready to close this as a non-issue with your work. 👍
Thanks again for building a fantastic tool! I've really enjoyed working with it. And thanks for your quick response and willingness to help. I may post something over at Bugzilla about this. We'll see, maybe it's just my local machine...
I see you've been working on this for a few years now. Do you have a Gittip account?
Ah yes, I see the discrepancy now. Thanks for posting a link showing the "no centering" workaround.
For the moment I am going to chalk this up as an edge-case, Firefox-specific bug and close this issue. If you find a rule that can be added to the CSS output, please reopen this issue and we can revisit it to prevent others from having this problem. I'm happy to hear you're finding Stylie useful!