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

[Ian Hickson]

On Wed, 18 Oct 2006, Neil Deakin wrote:
> 
> Is the DragEvent supposed to inherit from Event? Wouldn't at least 
> UIEvent be more reasonable?

Changed.


> 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?

Sure. Copy and paste, for example.


> > 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.

By "similarly" I meant "similarly", not "identically". As in, the 
initUIEvent() method, initMouseEvent() method, etc. In due course I'm 
hoping DOM Events 3 will have a terminology I can use to make this less 
ambiguous; until then I'll just leave it as is.


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

I've added dataTransfer to the init methods.


> 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)

The former. (The spec seems unambiguous on this point.)


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

Nothing especially interesting. (Again, the spec details everything that 
happens, and since nothing is specified to happen for these cases, nothing 
happens.)


> 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'.

Fixed.


> 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?

The latter, though nothing stops the user agent from letting the user 
select the text in some other fashion (e.g. using the keyboard, or by 
requiring a modifier key to be pressed, etc). This is similar to how it is 
not possible to select text that is part of a link in most browsers.


> > 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.

I've added an issue box for us to look into this.


> 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?

Well, if we want to expose this to authors, we have to define it.

I see your point, though. Maybe we should expose the types, at least? We 
can't expose the data for security/privacy reasons, but I could see 
arguments for exposing the types... is it safe enough? (I'm thinking a 
"types" subobject on dataTransfer, which is an enumerable list of types, 
e.g. a DOMStringList.)


> 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.

Good point. I've added an issue to this effect. I haven't defined it yet 
because I need to look into how exactly to expose this -- other events 
have the same problem (in particular, the 'show' event for context menus).


> 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>?

Yes (and the current drop target becomes the body).


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

Yes.


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

It's always 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.

It's not really specified in that much detail; which part of what is 
specified now do you think should be removed, and why?

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'