W3C home > Mailing lists > Public > whatwg@whatwg.org > November 2008

[whatwg] Drag-and-drop feedback

From: Ian Hickson <ian@hixie.ch>
Date: Wed, 26 Nov 2008 01:52:51 +0000 (UTC)
Message-ID: <Pine.LNX.4.62.0811260101270.17414@hixie.dreamhostps.com>

(Note: feedback relating to drag-and-drop of files from the filesystem, 
with possible uploading of content, isn't included in this e-mail. I am 
waiting to see what happens with the Web Apps File Upload spec.)

On Mon, 30 Apr 2007, Jon Barnett wrote:
> On 4/30/07, Ian McKellar <ian at mckellar.org> wrote:
> > On 4/25/07, David Hyatt <hyatt at apple.com> wrote:
> > > The use case of being able to drop images into a contenteditable 
> > > region and have them show up as <img> elements at the appropriate 
> > > place and then get automatically uploaded somewhere is a really 
> > > compelling one.
> 
> Is there already an API for knowing exactly where something is dropped? 
> Possibly - an empty Range object as either the relatedTarget or part of 
> the detail of a drop event.

There isn't, but isn't the cursor moved to the drop target position 
automatically in most systems? And in systems where that doesn't happen, 
shouldn't the drop happen where the cursor is anyway?


On Wed, 18 Jun 2008, Neil Deakin wrote:
>
> The initDragEvent/initDragEvent methods take a DataTransfer as an 
> argument. Is it expected that the DataTransfer to use here can be 
> created with 'new DataTransfer'?

No. If you really wanted to create your own DragEvent object, you'd have 
to "fake" a DataTransfer object using a JS object that happened to 
implement all the right attributes and methods.


> IE and Safari allow a no-argument form of clearData as well which clears 
> all formats.

Added.


> The description for the 'types' property implies that this should be a 
> live list. Why?

Why not?


> The clearData, setData and getData methods should clarify what happens 
> if an empty format is supplied.

Done.


> I still don't understand the purpose of the addElement method. Either 
> this should be removed or there should be clarification of the 
> difference between addElement and setDragImage

Added a note.


> Previously, I said that DragEvents should be UIEvents. I think they 
> should instead inherit from MouseEvent.

Done.


> We have a need to be able to support both dragging multiple items, as 
> well as dragging non-string data, for instance dragging a set of files 
> as a set of File objects (see http://www.w3.org/TR/file-upload/) from 
> the file system onto a page.

Agreed, but I haven't added anything for files yet because I'm waiting for 
that spec to stabilise.


On Fri, 20 Jun 2008, Robert O'Callahan wrote:
> On Thu, Jun 19, 2008 at 9:31 AM, Thomas Broyer <t.broyer at gmail.com> wrote:
> >
> > That's how Adobe AIR solved the problem. They added a Bitmap and File 
> > list data formats, for which getData returns AIR-specific objets (a 
> > BitmapData and an array of File objects respectively)
> 
> Creating a new data format for each kind of collection seems suboptimal. 
> And it breaks completely if you want heterogeneous collections.

It would be useful to have a clearer description of use cases for this 
kind of thing. When would an app be dragging a mixed bag of stuff like 
this? (That aren't all files, and that can't all be described together as 
a single piece of data with a single type.)


On Thu, 14 Aug 2008, Greg Houston wrote:
>
> [...] something lacking in the HTML5 drag and drop specification is the 
> ability to define a handle for the element that is being dragged. With 
> the drag and drop in javascript libraries you can define a handle (a 
> different element) that drags the draggable element. If the handle 
> property/attribute is null then the element itself is it's own handle.

Isn't that just dragging the handle?

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
Received on Tuesday, 25 November 2008 17:52:51 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:07 UTC