You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The animation is translateX: ["0%", "100%"] on a newly-inserted element, such that the force-feeding should cause the element to start off to the side. But I see it flicker in the untranslated position first. It doesn't happen every single time, but at least one out of three on my test ipad.
If I insert the element with display: none and pass a display option to velocity, the flicker goes away. But if instead I clear the inline display style myself in a begin callback (or before invoking velocity), the flicker remains.
The text was updated successfully, but these errors were encountered:
Yeah, I see why that flicker wouldn't go away in the case of trying to do it yourself in a begin (as I had suggested): the display property isn't being set close enough to the rAF tick's DOM update.
As you know, your particular issue has nothing to do with Velocity itself, but rather it's an overall timing issue. So, why don't you start with your element pre-positioned (via CSS) at translateX: 100%?
This is the flash of pre-animated content issue that I mentioned in #184. It happens on iOS:
http://jsbin.com/denabaju/1/edit
The animation is
translateX: ["0%", "100%"]
on a newly-inserted element, such that the force-feeding should cause the element to start off to the side. But I see it flicker in the untranslated position first. It doesn't happen every single time, but at least one out of three on my test ipad.If I insert the element with
display: none
and pass adisplay
option to velocity, the flicker goes away. But if instead I clear the inline display style myself in abegin
callback (or before invoking velocity), the flicker remains.The text was updated successfully, but these errors were encountered: