[Bug 14633] New: Drag source and drag destination can't coordinate behavior.

http://www.w3.org/Bugs/Public/show_bug.cgi?id=14633

           Summary: Drag source and drag destination can't coordinate
                    behavior.
           Product: HTML WG
           Version: unspecified
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: HTML5 spec (editor: Ian Hickson)
        AssignedTo: ian@hixie.ch
        ReportedBy: bytecrafter@gmail.com
         QAContact: public-html-bugzilla@w3.org
                CC: mike@w3.org, public-html-wg-issue-tracking@w3.org,
                    public-html@w3.org


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.

-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

Received on Monday, 31 October 2011 18:43:07 UTC