[whatwg] Comments/Questions on WebApps Drag and Drop API

Wed Oct 18 12:34:55 PDT 2006

Some comments and questions:

5.5.1

Is the DragEvent supposed to inherit from Event? Wouldn't at least 
UIEvent be more reasonable?

I'm not familiar with accessibility for drag and drop. Do platforms 
actually have a means of performing drag and drop that aren't mapped to 
mouse events?

 > The initDragEvent() and initDragEventNS()  methods must initialise 
the event in a manner
 > analogous to the similarly-named methods in the DOM3 Events 
interfaces. [DOM3EVENTS]

There aren't any such methods in the DOM3 Events.

What happens when a script creates a drag event by calling 
initDragEvent(NS) and dispatching it? Should dataTransfer always be 
empty is this case?

Is the addElement method used solely for the purpose of setting the 
image for dragging? Or, does it imply that the element itself is being 
dragged? (And that, for instance, dragging it into an HTML editor might 
copy the source for the element)

What happens if setData, setDragImage, or addElement are called during 
any of the drag events other than dragstart?

5.5.2

In the chart, the dragend event has 'current drag target' listed for 
dropEffect, yet the text two paragraphs later says that this should be 
'none'.

5.5.3

What happens in the following case:

<div draggable="true">
 <p>This is some text. <strong>Stronger text</strong></p>
</div>

Normally, starting a drag operation on html content, indicates to start 
a selection, not drag it. In the sample above, should a selection be 
started, or does this imply that the entire div is draggable when 
clicking and moving the mouse anywhere upon the text, and that it isn't 
possible to select the text by starting a selection within it?

 > If it is a selection that is being dragged, the dataTransfer member 
of the event must have
 > the text of the selection added to it as the data associated with the 
text/plain format.

Is that the only format that should be available? Mozilla's internal 
drag and drop APIs also supplies a selection as serialized HTML using 
the format text/html (or images as an image type). Maybe the spec should 
clarify that the UA may supply additional formats if desired.

If the data isn't available until the drop, there really isn't any way 
to know what to set dropEffect to during dragenter or dragover events, 
since it isn't known by the current target whether the data can be 
dropped there, not what drag effect can be used. The only real option 
would be to say 'yes, something can be dropped here, but if you try to, 
we still might not let you, and the drag cursor was just plain wrong'. 
So why does the spec go into such detail about what the effect should be?

The spec makes no mention of the modifier keys when the drag is 
occurring. In fact, it seems to imply that the modifiers must be ignored 
when determining the drag cursor to use, and to use only the 
effectAllowed and dropEffect states. Normally, the modifier keys force a 
particular effect, if allowed, to be used.

Just to clarify, the dragenter is sent to the current drop target, and 
then if not canceled, another dragenter event is dispatched at the <body>?

Is the dragend event fired regardless of whether a drop occurred? (i.e. 
was successful or canceled)

Typically, for move operations, the node may now be in the new location, 
should the dragend event still be fired?

Personally, I think that the behaviour of textbox drag and drop is 
implementation specific, and the spec shouldn't define how text gets 
moved or copied from/to them.

/ Neil