Bug on transition about balloon.css HOT 8 CLOSED

@gjdipietro Yes this might work, but because the translate property is being used to center the tooltip, it would have to use a different property to enable hardware acceleration. backface-visibility: hidden; seems to work in my testing.

from balloon.css.

It's been 3 years since this issue and I have not seen it happen anymore in current browsers. v1.0 also is getting different transition/arrow threatment so until v1.0 is released I will treat this as a solved problem.

from balloon.css.

@davesnx I went through this issue when building Balloon.css and could not find a solution. There will always be a pixel difference on the transitions. This happens because ::before and ::after are elements with different content animating independently, one may lag more than the other when transitioning, which leads to the "gap" or "stack".

I think there is no much that can be done here, other than removing the tooltip opacity to prevent user from noticing one pseudo-element stacking over other.

from balloon.css.

I was wondering that is caused by the transition on ::after happens a little bit early than ::before and that causes the 1px of difference.

I figure it out change the easing on the after for match perfecty, but it's pretty hard, tbh, the workarround can be add 1px on positioning and overlapse 1px of black inside the container on the animation (that looks a little bit better), what do you think?

from balloon.css.

The other problem is that this "lag" between pseudo-elements happen exclusively because of browser rendering, thus making adjustments on easing itself would only solve the issue on your own machine. Other machines with other hardware could probably lead to different delays.

I think the best solution for this would be overlapping the "arrow" 1px up as you said. However then we will have to remove the opacity of the tooltips (no big deal tho).

from balloon.css.

I don't think it has anything to do with lag. I think its a sub-pixel interpolation vs. pixel snapping issue. If you slow down the animation, you can see that the edge of the tooltip is using sub-pixels when moving. See attached.

Here is an article from Paul Irish that might help explain it. http://www.paulirish.com/2012/why-moving-elements-with-translate-is-better-than-posabs-topleft/

from balloon.css.

@joshbader Interesting. I've replaced the animation with translate() instead of translate3d() and the issue remains. But using margin seems to solve the problem (probably due to margin property using real pixels instead of sub-pixel interpolation).

However as far as I know margin property can't make use of hardware acceleration for animations. Not sure if will-change enables it, but its support is not that good anyways.

For smaller tooltips, using margin animations will probably not have any impact at all.But on bigger ones, with lots of text and/or glyps, the performance may drop, specially on small devices.

from balloon.css.

@kazzkiq could you force hardware acceleration on webkit browsers with translate3d(0,0,0) and enable the animation with margin? See more, https://davidwalsh.name/translate3d

from balloon.css.