[whatwg] Comments/Questions on WebApps Drag and Drop API
enndeakin at sympatico.ca
Wed Oct 18 12:34:55 PDT 2006
Some comments and questions:
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
> The initDragEvent() and initDragEventNS() methods must initialise
the event in a manner
> analogous to the similarly-named methods in the DOM3 Events
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?
In the chart, the dragend event has 'current drag target' listed for
dropEffect, yet the text two paragraphs later says that this should be
What happens in the following case:
<p>This is some text. <strong>Stronger text</strong></p>
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
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.
More information about the whatwg