Jump to content
GreenSock

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

iDad5

ShockinglyGreen
  • Posts

    216
  • Joined

  • Last visited

About iDad5

Profile Information

  • Gender
    Male
  • Location
    Munich, Germany
  • Interests
    art, sports (running, biking ...), single-malt, life in general

Recent Profile Visitors

1,981 profile views
  1. I wouldn't think so from what I can see. Without knowing your specific Task, I would advice you to first think of how you would achieve the animation itself. Layers or masks come to mind. maybe even video. Once you have the animation (as a timeline) connecting it to ScrollTrigger or maybe even (only) observer shouldn't be to hard. Go step by step.
  2. it is indeed a typescript thing. But it is a bug or an oversight in the Typescript-definitions provided (by Greensock) for the Observer-Plugin. The type of the target in the interface ObserverVars is provided as gsap.DomTarget, which in turn can be either an Element, a string, null or an Array(Like); window however is neither of those. Therefore Typescript throws an error when trying to transpile. Your hint that window is the default provides a possible solution - just not write it out. I would rather not go down that road however. I have for now solved the problem by extending the definition for gsap.DOMTarget with EventTarget but that might be to broad. Maybe just allowing window in addition to gsap.DOMTarget in the observer-definitions would be wiser. Or adding window to gsap.DOMTarget as this problem might extend to other areas? As far as I understand it Blake used to fix similar problems in the past and I'm sure he or whomever maintains the Typescript- definitions will have a good solution to be included in the next Update.
  3. Hi all, I was trying to use the Observer-Plugin in and wanted to set the target to window, but TypeScript informed me that window wasn't a valid gsap.DOMTarget which seemed logical when inspecting the gsap-core.d.ts. I temporarily added Eventtarget to type DOMTarget in my project, and speculate that that might be a good idea - or not? Anyhow I would love to see a fix, or be educated how to do better. THX
  4. Not to contradict Jack, für all intents and purposes it it true that accessing pseudo Elements with JavaScript is not possible. I found myself in a situation some time ago, where I had a very specific use case an I worked with window.getComputedStyle(element, ':before') to get the content and some other properties. In my case i was able to recreate the pseudo-element in a regular child element, place it while setting the original to invisible. It was a hacky thing, as I wasn't able/supposed to rework the original HTML-output and it worked under the given conditions but might not work under others - at lest not in an acceptable way. In your case ist seems to me that It might not unworkable, but there are likely better solutions.
  5. Actually it is not for Mobile-Safari. (the solution in your third link is based on that fact) 100vh measures the height of the viewport including the address-bar even when it is visible, while window.innerHeight at every stage returns the actual visibel screen-area. 100vh does not change when the address bar retreats, window.innerHeitgh does. My script is in fact working well, is is just not as elegant a solution I would like it to be. (Im going for 90vh as smaller values might give unconclusive results in actual browser resizing scenarios when the browser is only slightly resized, and going for 100vh would run the risk of influencing the body height unduly)
  6. My question is not strictly related to GSAP but the problem of viewport resizing and the mobil browsers hiding the address bar very often gets problematic in conjunction with gsap - at least for me. I've long since used a little utility class that watches for window resizes and reports them with a delay. (I'm sure I'm not the only one.) To get a handle on this address-bar hiding I reworked my class to discover when resizes are fired (solely) due to this address-bar hiding. Essentially I use an invisible div of 1px width fixed to the body and an height of 90hv if the window.innerHeight changes but the computed height of that element stays the same I have a very high probability that the resize event has been fired due to the dynamical hiding of the adress-bar. (I do a little more stuff to make the guess even better, but I spare you the details) I'm posting this, as I would be interested in the opinion of the learned people that roam this forum on some points: Does any of you have a way better method to achieve what I do? Namely I'm not to happy with a semantical useless div hanging around in my page - but always removing it and building it anew also seems nonsensical. (I've made it invisible and set it not to receive clicks and put a negative z-indes on it for good measure) But maybe someone knows of a way to calculate the (pixel-)size of vh without measuring an actual dom-element?
  7. Thanks @akapowl. Your demo helped me a lot. I will probably implement both versions (native onScroll and the ScrollTrigger based variant) an do some testing and will report my experience.
  8. Sounds crazy and probably is... I have a page that has a komplex 'opening-sequence' that runs either automatic or can be controlled by the user via ScrollTrigger. When fully opened I have a fixed header of a fixed height (depending on the Page width.) The original ScrollTriger ist killed by the end of the opening-sequence. If the page is higher then the viewport I want to shrink the header, moving elements to the sides etc... I first went for a timeline that rearranged the header content and after that worked the way I needed it, to I went about to add a ScrollTrigger to control it. Maybe I was doing it all wrong but I couldn't get it to work. One reason was that I make heavily use of css variables, and animating them with gsap is very cool but at least one of the variables that is crucial to the header also influences the body margin, therefore in some it produces a jittering loop half way... My solution would be just to work with native Window.scroll and doing the math based on percentages. BUT The way browsers (used to) report scroll events was often problematic in past projects and being an admirer of @GreenSock's work for years now I understand that a lot of optimizations are worked into the gsap solutions. SO So is it, in your learned opinion, useful and possible to use ScrollTrigger simply as a kind of proxy to report Window.scroll? And if so, how would you go about it?
  9. I’m pretty sure that it’s not so much a problem with ScrollTrigger as it used to work well, when I first implemented it. As I said the whole system is rather complex and I have to kill and rebuild the ScrollTrigger according to user behavior. That might be causing issues and I might have made a logical error somewhere. For the moment I’m fine with my solution but if I find the time to revisit the potential issue I will. If I find that there is an actual problem with the ScrollTrigger event I will try to build a ‘minimal’ demo, as I like a challenge.
  10. That should have jumped on me and bitten in my behind... Thanks for pointing it out. For reasons I don't fully understand I had to change my code to use the JS native scroll-event on the scroller eventually. Yesterday using ScrollTrigger's scrollStart event seem to work fine, today however. It seems the scrollStart Event doesn't fire reliably or maybe not fast enough for shorter waiting times. Most likely though I guess I messed something up.
  11. @Shrug ¯\_(ツ)_/¯ I feel you. It is an intriguing concept, but it has some complexities. The way @GreenSock set ScrollTrigger up is totally genius especially all the (necessary) performance optimizations built into it. In my (our) scenario though the fact that a lot of things are prepared when instantiating the ScrollTrigger(s) takes some mind bending for an old mind like mine. For technical and logical reasons ist simply often not possible to change a SrollTrigger instance on the fly, you have to kill and rebuild it - at lest that's what I found. Probably I was just using it the wrong way. It was a bit tricky and certainly not cost efficient (at least in my use-case it was more 'l'art pour l'art') but in the end it's always just impressing what magic greensock tools have built into. Also humbling :-).
  12. Using ScrollTrigger.addEventListener('scrollStart') did the trick. I misunderstood the documentation, thinking that if worked more like the onEnter callback. Thanks for helping me out! I share my additional learnings for maybe it'll help someone else to figure it out faster: My solution didn't work for two reasons, the ScrollTrigger.trigger is the element that is 'moved' the scroll-event however is fired on the element that holds this element. I tried to solve this by targeting the .parentElement - but as i was using pining however the pin-spacer created by ScrollTrigger was that parent and the container element that received the scroll-event was the pin-spacers parent...
  13. Thank you both. I had seen the events 'scrollStart' and 'scrollEnd' and I likely misread their functionality and somehow I didn't like that they were static methods. I would have preferred it to be only connected to the scroll of the specific instance but that's very theoretical I guess). I'll give it a try, especially as my solution actually didn't work. The scroll event on the target didn't fire. (I have a rather complex css construction and scrolling works, but I cannot figure out which element is actually scrolling - neither body or window worked.... One never ceases to learn)
  14. Thanks @akapowl but that wouldn't work. I need an event i can listen to with addEventListener. If that event isn't firing for (let's say) 2 seconds I play the timeline. Right now I'm using: ScrollTrigger.getById('stageOpenScrollTrigger').trigger.addEventListener('scroll', this.resetScrollInactivityTimer); That works fine but is somehow hard to read. A SrollTriger('s instnace) native event would feel somehow clearer and saver to me. But probably that event does not exist as it would add to complexity and could potentially cost performance.
  15. Situation: I have an animation sequence where at some point the user can take over control of the animation and scrub it (using ScrollTrigger of course). I need the sequence to be finished to go on with the rest. So if the user takes control by scrolling, but does not finish the job (no onComplete callback) I have to watch for this inactivity and auto-play the associated timeline. So I set up a timeout and if that is reached I just play the timeline. I just need to kill that timer when/if the user continues to scroll in that period. I can always listen to a generic JavaScript scroll event to accomplish this, but it would somehow feel more consistent to me if I could listen to a ScrollTrigger 'isScrolled' - or something like it - event. I could not find something like it in the docs and it might just not exist, but maybe one of you super Heros has a suggestion?
×