It seems that the HTML5 Drag and Drop API enforces a separation between the drag source and the drag destination (the two "sides" of the DnD operation). In general, this is a good thing. However, there are cases where one side of the DnD operation should definitely know about the other side.

In particular, I tried implementing drag-and-drop lists using HTML5 DnD. The list data is stored outside the DOM. When moving an item between lists, each side was responsible for updating its own data - the dragged element would remove itself from the source lists's data (during "dragend"), and the drag target would add the dragged item to the destination list's data (during "drop"). The problem, though, is that the move semantic has been lost. By decomposing a move into an insert followed by a delete, we may end up doing more work than we need to. Decomposing a move into an insert and a delete also breaks the atomicity that a move operation would suggest. Finally, the separate operations also imply the creation and destruction of data, which may introduce data inconsistencies. In my case, besides updating the Javascript data structures, the move operation eventually causes an asynchronous HTTP request to be sent. In this HTTP API, a move is very different from a insert/delete pair. 

In the case of a move, we want to update all the underlying data in one operation. That implies that we need only one side (either the source or the destination) to be responsible for updating all of the data. And this is where the HTML5 DnD spec falls short. As far as I can tell, there is no way for the source element to determine the drop target element, and there is no way for the drop target element to determine the source element. The only way that the two DnD sides can communicate is via the dataTransfer object. One thought would be to somehow put the source element into the dataTransfer object. However, since the dataTransfer object only supports files and strings, this won't work in the general case. Furthermore, this seems an abuse of the dataTransfer object, which seems like it should deal only with representations of the underlying data.

Although I don't have a lot of experience in this area, most desktop application libraries seem to include some provision in their drag-and-drop support to allow a drop destination to discover its paired drag source. For example, Cocoa sends the DnD source (often the NSView that initiated the DnD operation) along with all messages to the DnD destination. WinForms seems to include the drag source in the object that is sent to destination object events. In these libraries, the drag source is explicitly communicated alongside (not within) the DnD data store.

To address this gap, I would recommend using the relatedTarget property of the "dragEnd" and "drop" events. In the case of the "drop" event, relatedTarget should be set to the source element (i.e. the element to which the "dragEnd" event will be sent). In the case of the "dragEnd" event, relatedTarget should be set to the Current Drop Target (i.e. the element to which "drop" was sent). It might also make sense to set this property for the "dragover" event, but I haven't thought through that yet. In the current draft, relatedTarget is null for all DnD events, so I don't believe that this will cause any problems.