Jump to content
GreenSock

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

GreenSock last won the day on August 20

GreenSock had the most liked content!

GreenSock

Administrators
  • Content Count

    13,189
  • Joined

  • Last visited

  • Days Won

    411

Everything posted by GreenSock

  1. Glad to hear you're enjoying the tools! What you're asking for isn't exactly a super simple case, but here's one approach: https://codepen.io/GreenSock/pen/vYByKZN?editors=1010 Is that what you're looking for? Hopefully it's easy to dissect. Happy tweening/dragging!
  2. Yep, I see the same thing. Ha. Yeah, that certainly seems like an incorrect namespace.
  3. Yeah, I totally get that. Makes sense. Hey, if GSAP 2.0.2 is working well for you and there really aren't any pain points, why risk the upgrade? I did put a fix in for the issue we're discussing here, so it may very well be worth the risk in this case. Let me know if there's anything else we can do. Happy tweening!
  4. It seemed like a browser (or other environment) bug where [only in that particular environment] createElementNS() produced an element whose "style" was completely inaccessible! Weird, right? I can't imagine it's related to GSAP in any way. Is there a reason you don't want to update to the latest GSAP? Just curious.
  5. Well this is pretty ambiguous because technically this is like defining two different color values that you're asking the tween to animate to at the same time - one from the className and one from the "color" you're defining in the tween itself. Like @ZachSaucier said, we really don't recommend className tweens because it requires literally analyzing every single property, finding the ones that are different and animating those. It's much cleaner to just tell GSAP the specific properties/values you want to animate (plus I think that makes your code more readable and direct - less ambiguity).
  6. Have you tried using the Draggable instance's pointerX and pointerY values? That's one of the ways it smooths out cross-browser differences. And to be clear, the docs don't indicate that the event will always have pageX/pageY values - it has no control over that. It simply passes along whatever it gets from the browser.
  7. Yeah, I'd guess that is indeed related.
  8. Is it something Draggable-related? If you need help, feel free to share more details. But yeah, I think that as long as you're trying to straddle between your own native handlers of click/touch/pointer events and using Draggable (which smooths most of that out), I'd guess you'll have your hands full
  9. I didn't have a lot of time to look at this, but there are some inherent challenges with scrolling on iOS. If you look at the scrollbar, you'll see that Draggable is indeed being responsive to your touch but iOS is counteracting it in certain cases (no doubt it's trying to be "helpful"). I'd probably avoid the whole scrollTop thing and just affect transforms instead, kinda like this: https://codepen.io/GreenSock/pen/mdbPaqv?editors=0010 Is that any better for you?
  10. I doubt that is possible. It is a Flash player limitation I believe.
  11. I know it's solved, but just to chime in - if your goal is to add a perspective(999px) to the transform while it's animating, you could try doing an onUpdate: tl.tl(element, 2, {scale:0.7, onUpdate:function() { element.style.transform += " perspective(999px)"; } }); Just a thought. It could be made even easier with a helper function that'd automate some of that. Anyway, happy tweening!
  12. That's very tricky indeed, as you're trying to use a native "click" listener instead of Draggable's built-in onClick functionality, but you're still making the same element draggable and in my opinion that's a bit risky because various browser handle things very differently. For example, some browsers require that you preventDefault() on the initial pointerdown/touchstart/mousedown event in order to avoid touch-scrolling while you drag...but if you preventDefault() at that point, then when you pointerup/touchend/mouseup, it won't recognize it as a "click" even if you don't preventDefault() that final event. Other browsers DO treat that as a click event regardless. I could go on and on about all the differences and bugs in browsers surrounding touch/drag/click behavior. In your demo, it looks like sometimes the browser would dispatch the native "click" event first, but other times it lagged just a tiny bit behind the pointerup/touchend/mouseup event that Draggable taps into. I made a timing adjustment in this version of Draggable which seems to resolve this particular issue: https://s3-us-west-2.amazonaws.com/s.cdpn.io/16327/Draggable-latest-beta.js but beware that it can't possibly solve other inherent issues related to trying to mix native event handlers with draggable events. Unfortunately, dealing with all the various browser quirks is just a nightmare. Draggable does a really good job of normalizing things that you run through it, but if you're trying to straddle between letting it handle some things and using native events for other things...well, good luck with that I can only really control what Draggable does with its own behavior. Hopefully that tweaked version helps. I'd love to hear how it performs for you.
  13. Any chance you could provide a reduced test case? I'm curious about this. Keep in mind that some browsers cannot report an SVG's bounding box unless it's visible in the DOM.
  14. Oh, I didn't mean that your most recent demo had customizations made to GreenSock tools - I was just trying to be clear about what would make the ideal reduced test case. You've posted some other stuff that did include customizations, so I figured I'd mention it, that's all. That's what triggered my request for the most simplistic, basic reduced test case. Your codepen has a ton of other code that might (or might not) be causing issues. The goal was to isolate things as much as possible so we can get you an answer quickly and identify things accurately. It's just tough to parse through 400+ lines of code and try to understand what exactly your issue is, that's all.
  15. No. I'm not sure why you'd think that. The purpose of the snap function is to run logic every time the pointer moves when dragging, so that it can apply any snapping necessary at that point. I'm not really sure what I'm looking for, but I see 3 different sliders. I assume you're talking about the bottom one maybe? I can drag it just fine all the way up and down. It would be amazing if you could provide a very reduced test case without all the custom code in there - just the most basic thing you can possibly provide that demonstrates the issue. Hopefully less than 20 lines of code total would be ideal. Thanks so much!
  16. I haven't had time to read through your entire post or all the code in your demo, but I wanted to mention a few things and then you can let me know if you still need some help/input: In terms of snapIndex, wouldn't it be as simple as feeding the value into indexOf() to find what you need? There are actually a deltaX and deltaY values attached to the Draggable instance - would that help you determine the direction that you're after? Your getSnap() function seems to assume the type will always be either "x" or "y" (never "x,y" or anything else) which may be totally fine in your use case. I didn't follow what CS.context was (I did a search in the codepen and didn't find anything), nor do I understand what the "mean" was for. Are you trying to make it snap to increments of mean (starting at 0)? If so, that math looks right to me. I was confused by this comment - wouldn't you expect it to run on every move event so that your custom snapping logic can be implemented in whatever way you want? Like...we can't necessarily assume that if it's outside bounds, that your snapping logic won't apply some other rule. Of course that seems like it'd be pretty uncommon, but when we let users define a snap function, we've gotta keep things open, you know? And I doubt that there's gonna be some noticeable performance hit from running that logic between snaps or outside bounds. Perhaps I misunderstood what you meant though.
  17. I think I identified the edge case with edgeResistance intermittently causing problems (only when dragging outside the bounds of course) - it's just a rounding thing related to browsers only having a certain amount of precision when reporting the pointer's position. I posted the revised (uncompressed) Draggable here: https://s3-us-west-2.amazonaws.com/s.cdpn.io/16327/Draggable-latest-beta.js Better? I'm not sure that's at all related to what you were originally describing, @marya. Please let me know if there's anything else behaving oddly.
  18. Sorry about the confusion there - I've never seen that happen before but your demo helped me find a very rare edge case in the conversion algorithm where the arc command "a" could run into a Math.acos(-1) which JS returns as NaN (weird!), so I implemented a workaround and uploaded a revised MorphSVGPlugin. Seems to work great now! (you may need to clear your cache) Like others have suggested, tweaking your path would also solve the issue. But I want MorphSVGPlugin to be as bulletproof as possible Thanks for being "Business Green"!
  19. I'm a bit confused about the "why" behind all this - if your goal is to synchronize your audio with a particular timeline, wouldn't it be much easier to just use an onUpdate on that timeline and check the time(), compared to your audio's time and if it drifts beyond a certain threshold, make your adjustment to the audio?
  20. I couldn't replicate the issue you reported either, @Julius Friedman. Seemed to work fine for me.
  21. Hm, I'd definitely be curious to see a reduced test case showing the GSDevTools behavior you described, but I think part of the problem may be the way you're handling things. By default, GSDevTools "listens" for any animations that are created in the FIRST 2 SECONDS of the page load (you can configure that). It's just a much more complex thing to have a GSDevTools instance constantly listening for anything that gets created, and adjusting everything on-the-fly. So unless you must have global functionality (that's actually kinda rare), I'd strongly recommend linking a GSDevTools instance directly to a specific animation, like: var tl = new TimelineLite(); tl.to(...); //or whatever //now set the GSDevTools instance's "animation" to be your timeline or tween: GSDevTools.create({ animation: tl, // <- THIS IS THE KEY globalSync: false //and turn off the global synchronization }); Does that help at all?
  22. It's probably more complicated than you'd expect. It seems your statement was based on the assumption that start/end values are always stored cleanly in the vars object, but that isn't the case. For example, a bezier tween may contain an array of values with nested x/y pairs (or any property). And there are many other examples like that. Frankly, in all my years of doing this I can't remember anyone requesting this kind of functionality, nor have I needed it myself. Sure, there are times I may want to kill certain properties of a certain object from tweening, and that can already be accomplished with killTweensOf(). I totally appreciate your thoughtful suggestions and they're not without merit. However, when developing a product like GSAP, it's always a difficult balancing act between packing in as much functionality as I can while keeping the file size down and the performance way up...oh, and trying to prevent the API surface area from expanding like crazy to the point where it's just confusing/overwhelming for end users. I can't tell you how many times I've thought "well, in theory this feature might be cool..." or "oh, in this very specific use case, this feature would be nice to have..." and if I just keep cramming things in there, GSAP would end up becoming a monster. It's certainly possible to add code to the core to allow you to getTweensOf(target, property), but I'm struggling to convince myself that more than 0.01% of users would ever actually tap into that and I'm not sure it's worth the added complexity, kb, etc. Others are certainly welcome to chime in - if we get a lot of requests for that type of thing, I'd definitely reconsider it. But again, in all my years of doing this (and over 8,000,000 sites using GSAP including most award-winnings sites), I can't remember anyone else asking for that type of functionality. (That doesn't mean it's without merit). Again, I sure appreciate the thought you've put into these posts and your desire to help us make GSAP even better. I'm working hard on GSAP 3.0 and I think you're gonna really like it.
  23. Glad you got things working! And yes, that is a good way to prevent tree shaking 👍🏻
  24. Ha, you're the king of super long, complicated posts today Are you just making suggestions for potential feature additions to Draggable? Or was there a problem/bug you wanted to report? I'm not 100% sure I follow all that you wrote, but I'll mention a few things (none of which may be helpful): If you need both x and y involved in a snap, that's supported and here's a demo: https://codepen.io/GreenSock/pen/wgapaY If you want to sense the direction of the drag, there's getDirection(): https://greensock.com/docs/Utilities/Draggable/getDirection() We didn't implement *= or /= or %= because they're just not that useful and implementing them would force ALL users to pay the performance and kb hit for something that probably 0.00001% of the users may actually tap into. It just didn't seem like a good tradeoff. Your demo showing that scale:+=0.5 affected scaleX and scaleY seemed to work exactly as I'd expect. Am I missing something? Why would you not thing it'd affect scaleX and scaleY (scale, after all, is just a shortcut to affect scaleX and scaleY). If you still need some help with something, yes, it'd be REALLY good if you provided as reduced a test case as possible and please keep the threads focused on one question at a time if you don't mind. It's totally fine if you open a few different threads - it's just too convoluted and confusing for people to follow when a whole bunch of things are mashed into one really long post Have a good night!
  25. That basically means that "document" doesn't exist in that environment which is rather awkward because GSAP needs to tap into that in order to do various tasks. Think of it this way: it's like it's trying to run GSAP in a browserless environment (at least initially). It's the "server-side rendering" in Nuxt I guess. Did you read that link that @Dipscom linked to above? https://nuxtjs.org/faq/window-document-undefined/ Or if that doesn't work, can you just link to the files (perhaps on a CDN like cloudflare) instead of trying to run it all through an NPM-based build system that doesn't expose the document properly?
×