Why not use the mouseup target and not the old-school drag-n-drop position?

Question

So, from what I saw, almost all IE-compatible drag-n-drop uses positioning to determine where something is dropped. Performing something like mousedown, determine the position of all droppable, mouseup determine if we are in an inaccessible position. What for? I made a quick prototype, and it seems to work, which uses event.target for mouseup (in jquery, so that doesn't translate elsewhere) to define the drop element.

Is there a good reason not to do this? (use e.target for the mouse). Thus, mousedown determines that it is being dragged, and mouseup determines where it fell. Add some variable to make sure that we drag it, and remember that we dragged it.

Answer 1

My guess: because e.target on mouseup may refer to the element you are dragging (or its drag-ghost). If you drag an element and it (or a translucent ghost element) follows your cursor, as when dragging a file onto the desktop, your mouse will always be above the element that you drag when you click the mouse.

---

Alternatively, if there is no cursor and no ghosting, e.target may refer to the element inside the "dropzone element", and not to the area itself.

For example:

 <div id="dropzone_element"> <div id="previously_dropped_element" /> <div> <div id="draggable_element" /> 

So, if you drag and drop the drop element over the dropzone element and release the mouse, you will actually free the mouse over the previously dropped element inside the dropzone; not the drop itself.

In both cases, checking the mouse position is the only way to get the correct dropzone element.

That would be my guess, but I do not have IE to test the actual behavior.

---

Edit: in the 1st case, checking the position is the only way. In the second case, you can also check the target ancestors to find the dropzone element, as indicated by the afé in the comments. If, that is, a previously dropped element was actually inserted into the dropzone hierarchy, and not just positioned as if it were - although it would be very strange:

Answer 2

The first problem: there is always a lag when dragging and dropping items, especially in IE. And the mouse pointer may bypass or lag behind the drag element. Thus, when dragging and dropping, the pointer is inactive over the drag element, and for small drop zones it is not above the drop zone. Ajax libraries should consider this fact. And the only way to make it work predictably is to compare the drag and drop coordinates of the target.

Second problem: ajax libraries may give you the option to use drop handler . drop handler is an element that is not a child of dropzone, but it covers dropzone. Again, it is not possible to catch dropzone events. But coordinate comparison still works. Why is someone covering the fall zone? Suppose one has a table. And one of the cells is dropzone. And now someone wants to catch an event in the cartoon. One creates a div (#scroller) with the same size as the table, and places it on top of the table. Then he puts another scroller (#eventgrabber) inside the scroller. Eventgrabber is more complex than a scroller. Now one can catch the scroll event on the scroller. But in order to be able to drag cells, you need to designate eventgrabber as a drag & drop handler.