Jump to content

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


  • Posts

  • Joined

  • Last visited

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

madleo's Achievements


Newbie (1/14)



  1. Many many thanks for investing time into this, truly grateful and always great to see your examples. I'll be sure to try and learn as much as i can from this. Thanks Blake!
  2. Interestingly, keeping your original implementation and simply adjusting the scroll speed seemed to have done the trick. At least in Chrome / Android. The resize event is still firing but given the new range of values maybe the jump is too small to notice. let scroller; if (window.innerWidth <= 800 && window.innerHeight <= 730) { scroller = { target: document.querySelector("#playground-subcontainer"), ease: .5, // <-- scroll speed on mobile endY: 0, y: 0, resizeRequest: 1, scrollRequest: 0, }; } else { scroller = { target: document.querySelector("#playground-subcontainer"), ease: .05, // <--scroll speed on !mobile endY: 0, y: 0, resizeRequest: 1, scrollRequest: 0, }; }
  3. Hey Blake, Great to hear from you! Could you elaborate using your smooth scroll implementation? Or if you could elaborate a little more on the fixed body size approach.. I just tried the following.. body { // BEFORE // overflow-x: hidden !important; // overflow-y: scroll !important; background: #148991; height: 310rem !important; } a { cursor: pointer; text-decoration: none !important; } #main { // AFTER overflow-x: hidden !important; overflow-y: scroll !important; background: linear-gradient(to right top, #148991, #011219, #022531, #074757) !important; overflow: hidden !important; position: fixed; width: 100vw; display: -ms-flexbox; display: -webkit-flex; display: flex; justify-content: center; top: 0; left: 0; right: 0; bottom: 0; } Am I going in the right direction here? At this point the address bar still causes teh issue
  4. Nice man, site looks impressive! My site just requires two things -- smooth scroll + fading elements on scroll. For this I'm using Blake's implementation + Intersection Observer API. What I really like about Blake's implementation is it's purely JS, and JS that I can see/tinker with easily. I haven't tested my app on iOS but see this on chrome + android. To visually see what's happening, Found this video on a thread btw. The only workaround (if you can call it that) I can think of to address all devices, is to remove the smooth scroll functionality for mobile. Having trouble with this too. Tried going the JS + GSAP way, if (window.innerWidth <= 800 && window.innerHeight <= 730) { // remove and update classes TweenMax.set(this.el, { className: -=main}); TweenMax.set(this.el, { className: +=main-mobile}); }; Tried swapping css files dependent on viewport but having issues in a SSR Next.js environment. But still no luck. Seems like ViewportUnitBuggyFill is meant for legacy browsers on android where vh,vw units are not recognized. This is a concern too, but not quite there yet. I'm still working on getting this to work on modern browsers lol. As you can see, right now I'm leaning heavily on this forum lol.
  5. Hello Everyone, I've implemented Blake's smooth scrolling solution and am in love with it. With that in mind, I'm bashing my head the past 24 hrs on trying to get this to work in mobile. Blake's already addressed what the issue is, Has anyone found a workaround or even better, come up with a working solution for mobile? Any suggestions, direction, help on any level would be greatly appreciated.
  6. Ah, ok i see what you're saying -- thanks a lot for clarifying!
  7. That sounds right -- React takes a snapshot of the virtual DOM, compares with proposed updated DOM, then syncs/updates objects to the real DOM. At the end of the day we're targeting the real DOM. Could you elaborate a little more regarding the problems that refs would resolve? Specifically the one's you're alluding to: I think it might just be the way its phrased. Thanks in advance!
  8. Awesome. Really appreciate the level of insight. If I’m understanding this correctly (and allow me to summarize here) — The surest way to get GSAP and React working together is to leverage lifecycle hooks, in that you’re able to control the creation/start of animations only after the DOM has rendered or completed an update to the DOM. With that in mind, we mainly use componentDidMount and componentDidUpdate respectively. The most obvious reason for wanting to leverage lifecycle hooks is to prevent the situation where a tween target gets removed during an animation due to an update to the DOM. Although the approach of selecting elements through css selectors ‘works’ given that I’m placing the animation logic in componentDidMount/useEffect, it is not best practice, less safe, and thus prone to unexpected/unwanted behavior. Regarding React hooks — I completely agree, and understand that I’ve taken a risk in investing time into React hooks. I just couldn’t help myself. XP. Lastly, I would certainly love to see your implementation with React hooks (React in general), but if you have to go out of your way for this, no worries -- if anything I can try to whip up something myself and you can have fun demolishing it. I'll have a little bit of time tonight, and more so over the weekend. But when I do come up with something I’ll be sure to PM you. Thanks again!! @GreenSock @Rodrigo
  9. I think that qualifies as a "real" answer, haha. Definitely helps. In case @Rodrigo or another React vet has a chance to assist, allow me to briefly set some small context here. In a nutshell, I'm trying to find the most efficient way of utilizing gsap within React 16.7 -- more specifically, using gsap with the newly introduced hooks such as (useEffect hook), and without the use of classes. In the mean time, when i get a chance this evening I will continue tinkering and try to incorporate refs to ensure the best chance of expected behavior.
  10. Hi Team, Within the virtual DOM environment (Vue, React, etc), what's the difference between targeting/tweening an element using a ref vs selecting via css selector string (performance, known quirks/bugs)? I've been targeting/animating virtual DOM elements using css selectors, but just came across the "Getting Started: React and GSAP Animations" and see that using refs is advised. Perhaps I'm veering too far away from a GSAP specific question at this point, and if that's the case, understanding the difference between targeting with css selectors vs targeting the node/element directly would be certainly helpful. Thanks in advance!
  11. Sorry about the limited info, I've got it to work though thanks to you guys! In my case, it was Nuxt (SSR) related. if(process.browser) { CSSRulePlugin = require("gsap/CSSRulePlugin") } Thanks again!!
  12. Thanks for the welcome! No luck just yet. From server side, I'm getting "export 'CSSRulePlugin' was not found in 'gsap' I'm thinking this might be related to SSR? If so, might be Vue/Nuxt config I have to setup correctly, to which I'll try and figure out outside of this thread. Just to be clear though, I'm trying to use CSSRulePlugin within the context of npm.
  13. From reading NPMUsage docs and inspecting the available exports in gsap npm package, CSSRulePlugin does not seem to be made available. Is there a specific reason for this, or is this planning to be released sometime in the future? My goal is to latch onto pseudo elements like :after and :before. Is there another way to do this with GSAP? On a side note, I'm quite new to GSAP, and I'm trying to incorporate GSAP into a SSR Vue app (Nuxt). Thanks in advance!