jamiejefferson

Yes the mask is placed in the target element's coordinates, so it technically doesn't move when you tween the image. You can just create a counter tween to move the mask in the other direction at the same time http://codepen.io/jamiejefferson/pen/ngpIC

You were very close! - it seemed like you just had the #sheen and #sheenImage styles mixed up http://codepen.io/jamiejefferson/pen/zDxab (I removed #sheenImage entirely as it didn't seem to be needed)

Thanks for sharing. In case you weren't aware, there's one thing I'll point out regarding your last point about onComplete and opacity:0. If you want to make an element disappear at the end of a tween you could use the visibility style to toggle that. The benefit of visibility is that the element is totally hidden like opacity:0, but it also stops mouse events on the element so it may help improve performance. Visibility is handled smartly so that if you tween to visibility:hidden, it's toggled at the end of the tween, and if you tween to visibility:visible, it's toggled at the start. I haven't done a performance test (I imagine it's not worse) but at least it might make for a bit cleaner code. Something like this: TweenMax.to(foo, 1, { startAt: { left: 0 opacity: 1, visibility: "visible" }, left: 100, opacity: 0.5, visibility: "hidden" }); If you're using opacity and visibilty at the same time, the autoAlpha plugin can be used to combine them into one smart property that sets visibility:hidden when opacity === 0, or visibilty:visible at all other times. e.g. TweenMax.to(foo, 1, { startAt: { left: 0, autoAlpha: 1 }, left: 100, opacity: 0.5, visibility: "hidden" });

I'm sorry if I wasn't clear enough. chars = mySplitText.chars in your example. The loop just fills even and odd with alternating characters so you don't have to populate them manually.

The issue is related to this note from the docs greensock.com/docs/#/HTML5/Plugins/CSSPlugin/ GSAP tracks the values of transforms internally so setting through style causes a small conflict. If you let GSAP handle all applications of transforms then this shouldn't be an issue. If you want to keep the element.style.transform declarations, then you'll need to add parseTransform:true to your tween. TweenMax.set(unfiltered_image, { scale: 2.5 }); TweenMax.to(unfiltered_image, 1, { scale: 1, ease: Linear.easeOut }); // or unfiltered_image.style.transform = "scale(" + initial_scale + ", " + initial_scale + ")"; TweenMax.to(unfiltered_image, 1, { scale: 1, parseTransform: true, ease: Linear.easeOut }); // or TweenMax.fromTo(unfiltered_image, 1, { scale: 2.5 }, { scale: 1, ease: Linear.easeOut }); And since you're using TweenMax, you could really shorten this by adding a repeat and repeatDelay jsfiddle.net/6ojyt5bq/6/

Create two arrays and stagger them however you like var i = 0, odd = [], even = []; while (i < chars.length) { even.push(chars[i++]); if (i < chars.length) odd.push(chars[i++]); }

I think I'm missing something - how are you applying the position:"absolute" to fix it? http://codepen.io/jamiejefferson/pen/dxwFh

To clarify, I agree there is probably a small bug here - if you add a single space on one side of a <br/> tag it will add an extra line break that's not there in the original HTML - effectively a double <br/> where only one should exist.

That codepen is linking to a year old version of SplitText, although I'm not sure if this has been subsequently fixed. The description of the bug isn't quite accurate, although the different result certainly exists. It appears that SplitText is adding a phantom space after a trailing <br/> which gives the appearance of an extra, empty line, but reverting it is actually restoring the exact original HTML without this phantom. It can also be seen by including a <br/> surrounded by white space in the middle of text.

If you need the y direction of each mousemove, not relative to the starting position, you would only need to add one line to Rodrigo's example (or just move it...). Put this at the end of onDrag startPos = this.y;I'm still fuzzy on what the "lasthited" stuff is for, or how that is supposed to work. Is there another API you're drawing this idea from? It might be clearer if you could show us an example of the functionality that you think Draggable should be handling for you.

Oh it wasn't IE that was the weak link? Good one brain but something about the way it worked at the time convinced me to use jQueryUI (long before Draggable existed) anyway. gui - it looks like there was 17 minutes between my posts, so in that time I went and built it in jQuery (sometimes having a library is just better), then spent a few minutes taking jQuery out of it, then came back here to post. I guess I already had the logic in mind from my original suggestion so that helped?

Look, here's my original idea extrapolated to work on same-height elements. It's not the greatest solution, but for 5-10 minutes work it's not so bad. codepen.io/jamiejefferson/pen/iFDow/

I'm not sure if it's the language barrier or something else, but I don't really understand the problem you're having with hittest. Could you explain more about what you think is missing, and what y position you are referring to? I actually don't think hittest-ing is really necessary to create this effect, but I'm sure it will make more sense once I have a better idea of what you're trying to do with it.

Blake - I'm not too familiar with the HTML5 API for this. I investigated it a few years ago but it seemed like browser support (IE?) was quite lacking and never went back to it. I'm not sure how the dataTransfer object is used, but if it requires letting the browser handle drag and drop natively, then it's probably going to be difficult to integrate with Draggable.

It already exists... greensock.com/docs/#/HTML5/GSAP/Utils/Draggable/hitTest/ I'm confused why you would spend so many hours working on this if you know you could have it completed in an hour without GSAP?

Glad you've gotten it working. I'm not aware if/how you added allowDragging (sorry I misnamed it) to your actual project, but I still maintain that allowDragging is doing nothing in your codepen. There is no code that actually checks the value other than for a console log, and as such dragging is allowed at all times. I believe Rodrigo was just giving you a nudge in the right direction with the "// code here" bit needing some extrapolation. Just having an allowDragging variable exist does not affect the function of Draggable.

Blake has just offered one solution. Another would be to separate the fromTo() into the necessary from() and to() tweens: tl.from('#test2', 1, { x: -50 }) .to('#test2', 1, { color : 'red' }, "-=1");

No worries. In future, it might be less confusing to others reading the topic if you only use edits for tidying up a post, or adding new information, rather than clearing the entire thing. e.g. just add a message at the bottom like "still working, please ignore for now"

Hi, welcome to the forums. fromTo() isn't used for the purpose of combining to() and from() tweens into a single call - it's only used to create a tween where you know both the start and end values for each property of the tween. If you only have one of the values, you would just use from() (start values) or to() (end values). e.g. say #foo is at left:200, and we would like to tween it from left:0 to left:100. For this a single from() or to() tweens is not enough, and you would use fromTo() TweenLite.fromTo("#foo", 1, { left: 0 }, { left: 100 }); // would tween from 0 to 100, as intended TweenLite.from("#foo", 1, { left: 0 }); // would tween from 0 to 200 TweenLite.to("#foo", 1, { left: 100 }); // would tween from 200 to 100 For your codepen, it would probably be best to separate into 2 tweens: one for tweening to() red, and one for tweening from() left:-50

I'm not sure if it's because chagui keeps editing their posts or if I'm just being dumb right now - what's the dataTransfer object?

I'm a bit confused by your implementation of the fixes - you've kept boxX and boxY but never modify them now, and you've not added any logic that actually requires the allowDrag boolean, so it's providing no effect at all to the running of your program. There were also a few loops that had no purpose; those code blocks only need to be run once. I've cleaned it up for you and the behaviour is identical codepen.io/jamiejefferson/pen/...../ I am also seeing the bug that locks the draggable in a new position. I can fairly reliably reproduce it with just one or two clicks after dragging a few pixels. Still investigating... If you click on the element without moving the cursor it happens, because there was no drag and onDragEnd is used to 'reset' the element. If you change onDragEnd to onRelease it will always trigger - onDragEnd only triggers if there was an actual drag.

GSAP already has a plugin architecture for custom properties. For example, all of the CSS properties GSAP supports are technically "custom properties" of the CSSPlugin. You can get started with the template plugin provided in the download package at \src\uncompressed\plugin\TEMPLATE_Plugin.js

My suggestion wasn't to necessarily use jQuery; just to read their source code as an example. Their logic is just as viable as non-jQuery logic, so even if you don't use jQuery to implement, it's still a good place to learn if you don't know where to start. A basic way to calculate it might be to assume all elements are equal height: onDrag:function() { var indexChange = Math.round(this.y / this.target.offsetHeight); var bound1 = /*index of this.target inside its container*/; var bound2 = bound1 + indexChange; if (bound1 < bound2) { // new index is higher - move elements up } // etc }

Yep if (value > 360) value = 360; if (value < 0) value = 0;

Without going back over the earlier posts, what is the point of saving the boxX/boxY onPress? That's what's "resetting" the box position. The default x/y values for an object are always 0,0 so you could just be tweening back to 0,0 and avoiding this entirely.