Sortables: Issues with drop animation (wrong direction / undesired fade)

[slava-uxd]

Here is the fiddle demonstrating the issues:
http://jsfiddle.net/4g48odh6/

The dropped items in the fiddle are moving a fixed amount of pixels to top/left (in our dev environment there is no movement at all). I'd expect it to move into it's target location (all the way), but I cannot find any way to influence this. I couldn't find an option to turn the fade out effect either.

---

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

[timwienk]

It's not actually the dropped element that's moving/fading, it's the clone. The dropped element is already in place (and you added styles to it, to make it appear with a dashed line). I expect this is just a terminology thing, but I wanted to be clear.

I suspect the actual idea is that the revert effect would indeed move the clone to the dropped element's position (and size), and fade out meanwhile. Assuming this is the case, the goto-position is determined incorrectly (it finds its own position, rather than the dropped element's).

The fade effect would be there for a smoother transition, since the extra styles you added are not there in the default setup.

---

This first problem, the weird direction of movement, can be solved by making the container element an actual offsetParent (just add a position other than "static" to the parent ul, like position: relative).

Your second point, wishing to disable the fade, is a feature that is not supported by the current Sortables implementation. I guess this also the movement to target location, though that does strike me more as a bug. It's actually surprising no one mentioned this in the past.

---

I wouldn't really expect a new release of MooTools More any time soon, but you can easily create an extension of Sortables in which you replace the end function without any harm (or you can just Sortables.implement a new end function).

I think the only thing you'd have to do, is remove opacity from the morph effect, and change the pos values to be based on the dropped element, rather than the clone.

Something like this:

var MovingCloneSortables = new Class({
	Extends: Sortables,

	end: function(){
		this.drag.detach();
		this.element.setStyle('opacity', this.opacity);
		var self = this;
		if (this.effect){
			var dim = this.element.getStyles('width', 'height'),
				clone = this.clone,
				pos = clone.computePosition(this.getDroppableCoordinates(this.element));

			var destroy = function(){
				this.removeEvent('cancel', destroy);
				clone.destroy();
				self.reset();
			};

			this.effect.element = clone;
			this.effect.start({
				top: pos.top,
				left: pos.left,
				width: dim.width,
				height: dim.height
			}).addEvent('cancel', destroy).chain(destroy);
		} else {
			this.clone.destroy();
			self.reset();
		}
	}
});

[slava-uxd]

@timwienk This is amazing. Works like a charm! I would suggest making this a part of More by default, at least optionally available.

My original intent was to replicate physical behavior as much as possible. In a physical world things don't fade, disappear and reappear elsewhere or duplicate. From the usability perspective these unnatural things are a bad practice. That's why I (being well aware of that) styled the original element to look like a placeholder, to make it look like the actual element is being dragged and dropped. There is still one thing missing to make Sortables behavior natural. That is that other items should move away (animated) instead of jumping/teleporting away to make place for the drop placeholder (=original element instance in Mootools implementation). I want to implement this, but since you know the framework so well, can you point me in the right direction? Where do I start?

[timwienk]

I don't think that will be as easy to do, since the element is just moved in the DOM, and nothing is done style-wise.

If you want to give it a go, I think the place to start is to look into creating a new insert function for the extending Class. You'd have to decide whether it should animate first and then change DOM, or change DOM (while setting styles to retain old position) and then animate. (I think the latter option is safer.)

There are some additional aspects to look after, though. You'll have to account for animations being cancelled halfway through (by dragging further/back), any pre-existing styles/positioning of the elements, possibly multiple columns and/or non-vertical alignment and/or multiple droppable lists, even the "revert" animation going to the right place.

For your use case you might be able to leave some of those things out, but you might also run into more interesting things.