Jump to content

Search In
  • More options...
Find results that contain...
Find results in...


  • Content Count

  • Joined

  • Last visited

Community Reputation

11 Newbie

About gmullinix

  • Rank

Recent Profile Visitors

1,310 profile views
  1. I changed your "from" tween to a "fromTo" and it appears to animate as desired. Also, autoalpha automatically sets the "visibility" and "opacity" properties so no need to specify it in the tween. https://codepen.io/gem0303/pen/PoqGdyv
  2. Here's some places I have bookmarked. Obviously don't have to use the library, you can just recreate the effect on your own. Converting CSS animations to GSAP animations is good practice, too. https://tympanus.net/Development/PageTransitions/ jsfiddle version: http://jsfiddle.net/EbhdM/3/ https://codepen.io/chriscoyier/pen/ydrGYw https://codepen.io/chriscoyier/pen/EBLZVG https://www.minimamente.com/project/magic/ https://daneden.github.io/animate.css/ https://css-tricks.com/css-animation-libraries/
  3. @GreenSock Perfect, thank you for providing that! I will report to Chromium tomorrow. edit: reported here https://bugs.chromium.org/p/chromium/issues/detail?id=1054433
  4. @ZachSaucier Thanks for the link to info on the stacking context. The green squares already had a z-index (value of 70), and that was not changing anything. I added a z-index of 10 to the purple square and that didn't change it either. will-change: transform on the purple square didn't change anything. Here's some system specs for my desktop: OS Name Microsoft Windows 10 Home Version 10.0.18363 Build 18363 System Manufacturer Gigabyte Technology Co., Ltd. System Type x64-based PC Processor Intel(R) Core(TM) i5-6500 CPU @ 3.20GHz, 3201 Mhz, 4 Core(s), 4 Logical Processor(s) BaseBoard Manufacturer Gigabyte Technology Co., Ltd. Installed Physical Memory (RAM) 16.0 GB Total Physical Memory 16.0 GB Available Physical Memory 10.3 GB My coworkers were able to see the bug. Some of them have similar desktops and some don't (laptops, different manufacturers, etc). We are all running Windows 10. @GreenSock Can confirm that a negative z-index on the purple square fixed the issue. I also figured out that backface-visibility: hidden on the green squares fixes the issue too. When making the bug report, I wanted to link to a Codepen like I did here to help illustrate the problem. However, I'm not sure how to re-create it without Greensock. As demonstrated in the second Codepen, CSS animation doesn't appear to break. Any ideas?
  5. I'm noticing a strange issue when combining transforms and animations. Divs are being covered by other divs when they shouldn't be. However this only happens at large screen sizes, and only on Chrome and Chromium Edge. It's a little bizarre to explain and hard to replicate so please bear with me. Please view Codepen #1 at full screen and in "full page" view: https://codepen.io/gem0303/full/abOZyPK The green boxes should always be on top of the purple square. At HD size (1920x1080) it displays as expected. However, once you view it on a 4K monitor (either simulated with device mode or on an actual monitor), the green square on the right is covered by the purple square. Some comments about this: If you add force3D: false to the tween, the bug will not happen. If you remove one of the transforms (either on the purple square, or on #main_wrapper), the bug will not happen. The square's position on the gray stage can impact whether the bug happens or not. Originally all 3 squares were positioned on the left side of the stage, and there was no bug at any screen size. z-index doesn't help or change anything. This is where it gets weird(er). Please view Codepen #2 at full screen and in "full page" view: https://codepen.io/gem0303/full/poJbdoQ I added a second set of boxes which uses a translateX CSS animation to move the blue box. The presence of the CSS animation code fixes the bug. The green squares appear on top of everything at all screen sizes. The CSS animation has to be a transform, though. If you do an opacity animation, the bug comes back. ??? Additional comments: This same bug can happen if you are doing transform animations with png images. Sometimes the bug can happen at a 2K screen size. But it never seems to happen at 1920px width or lower. I'll probably end up reporting this to Chrome because it seems more their issue than GSAP's. However I wanted to see if anyone here had run into this issue or had any insight. The only consistent workaround we've found is setting the timeline default to force3D: false.
  6. I would also like to see this feature come back. There are certain cases where it's better to keep the css styling separate, and use gsap to animate the state change via "className".
  7. I changed my code as Zach suggested. Thanks for the quick update!
  8. If I create a paused timeline, its isActive() value appears to be 0 instead of false. Please check the Codepen for more info. Am I setting up the timeline incorrectly or is it a bug?
  9. Thank you for looking into this and putting a fix in the next release! I reported the issue on VideoJS's Github.
  10. Loading GSAP 3 and then VideoJS (in that order) breaks VideoJS. In my Codepen, the video is still playable, but VideoJS doesn't initialize and there's a few console errors. FYI If I reverse the load order, everything works fine. Any idea what's going on?
  11. I have an SVG path styled to look like a dotted line. I want the path to look like it's drawing in. I created a mask and tried to animate the mask path but it refuses to draw. In the Codepen example, I found that the mask animation worked if I modified the SVG and gave the path a few bends. Does the straight line confuse DrawSVG because it doesn't know what the start/end points are? How can I get the straight line's mask to animate? edit: Fix appears to be adding maskUnits="userSpaceOnUse" to the mask definition in the SVG. Stack Overflow link
  12. In the attached pen, the moving elements do not stay centered on the blue line. The triangle and balloon don't stay attached at their center origins at the "top" half of the blue circular line. They do align as intended on the bottom part of the line. Removing the xPercent/yPercent via the TweenLite.set does make them stay positioned closer to the blue line, but we want them to be centered the whole way around. Or, if you change the xPercent/yPercent to positive 50 instead of negative, it reverses the problem: the shapes attach correctly on the top half of the line, but not the bottom half. Any idea what is happening?
  13. Any update on this? (Apologies if you're still travelling and haven't been able to look into it yet.)