[whatwg] Drag-and-drop feedback

On Wed, Feb 3, 2010 at 6:29 PM, Ian Hickson <ian at hixie.ch> wrote:

> On Sat, 23 Jan 2010, Eduard Pascual wrote:
> >
> > Would it be possible to provide a list of "drag items" (to call them
> > somehow) instead of, or in addition to, the current info provided by the
> > DataTransfer object?
>
> That's a pretty good idea. I think we should probably do this when we add
> more types to the DataTransfer object.
>
>
> On Sat, 23 Jan 2010, Maciej Stachowiak wrote:
> > >
> > > The HTML5 drag-and-drop model (or rather, the IE drag-and-drop model
> > > that it is based on) doesn't really work for this case anyway,
> > > regardless of the copy/paste issue, since there doesn't seem to be any
> > > sane way to distinguish between an in-page drag and a drag to an
> > > external application such as a clipboard. If you can drag to a
> > > clipboard, I don't see why we would _disallow_ the copy/paste
> > > interaction.
> >
> > That sounds like a design flaw with the drag and drop model.
>
> One of many.
>
>
> > Sounds like something to fix not something to compound with another
> > design flaw.
>
> Fair enough. I've removed the copy/paste mode of drag-and-drop.
>
>
> I'll deal with the copy/cut/paste events separately.
>
>
> On Mon, 25 Jan 2010, Jian Li wrote:
> > > >
> > > > "DownloadURL". The data associated with the "DownloadURL" format
> > > > should be parsed similar to the "URL" format. When the drag ends in
> > > > another application, the remote file described in the associated
> > > > data URL should be downloaded and provided to the target
> > > > application.
> > >
> > > How would this be exposed to other apps? Is it possible in Windows to
> > > drop something and then have the application that received the drop
> > > wait for a download (which could take hours) to complete? How does
> > > that work?
> >
> > On Windows, [...] we use the file stream to transfer the data between
> > the source application and the target application and thus the target
> > application will not be blocked if it uses a background thread (this is
> > what Windows Shell does). On MacOSX, a file stream is also used for such
> > purpose.
> >
> > However, we need to provide more metadata about the download when we
> > call DataTransfer.setData("DownloadURL", ...). This is because on
> > Windows we need to know about the file name and size when the drag is
> > initiated. We can wait till we get the headers to extract the file name
> > and size but this is blocking. Even more, if the http chunk mode is
> > used, we cannot get the size from the headers.
>
> So how would you provide the file size?
>

After more investigation, I found out that we do not need file size info in
order to unblock the UI thread of Shell on Windows. This is because we can
use delayed rendering plus IAsyncOperation when dragging and dropping to
Windows Shell. However, many other target applications do not support these
advanced interfaces and thus could be blocked if the download takes long
time. Since dropping to Shell desktop or folder is the main scenario we want
to deal with, I think we're OK with this solution.

>
>
> > On MacOSX, we need to provide the mime type and file name. Could we
> > consider adding mime type, file name and size information into the data
> > value parameter of setData method? For example,
> >
> >    dataTransfer.setData("DownloadURL", "text/plain:1000:
> http://example.com/download.txt");
>
> I think we should just have a "promise" mechanism rather than one
> hard-coded for URLs. But I think it's probably best for us to wait until
> we have the current spec implemented reliably and sanely before adding
> something like that. We don't even have a good test suite for the
> drag-and-drop API yet.
>
> Yes, we probably need a better mechanism to describe the drag data. After
we get implementations up in all applicable platforms, we can have a good
understanding of what are needed and what are not and then we can define a
better API.

>
> On Mon, 25 Jan 2010, Michael Davidson wrote:
> > > >
> > > > The issue that I'm having is that if the DataTransfer object says
> > > > that it has Files, I have no way to determine what type those files
> > > > are. (In this case, I only want to accept image files.) I understand
> > > > that the DataTransfer shouldn't have the content of the files for
> > > > security reasons, but it would be helpful if it did contain the file
> > > > names and/or MIME types.
> > >
> > > I could provide a second attribute with the types of the files, would
> > > that work? I suppose if we did this, we should remove the "Files" fake
> > > type. That might not be a bad idea in general, it's kind of a hack.
> > > I'm not sure how I feel about having multiple different ways of
> > > representing the data in a DataTransfer object... It would give a
> > > clean precedent for adding other features, though, like promises,
> > > which some people have requested.
> >
> > Multiple different ways to get the same info doesn't seem great, but it
> > doesn't matter to me as long as the information is available.
> >
> > Another option is to throw an error if developers try to access
> > forbidden attributes during dragenter/dragover.
>
> I haven't added this for now, because Firefox 3.6 already shipped with
> Files and I think it'd be better to get the API stablised on what's
> already specified before adding more (and since it's shipped, I'd rather
> not remove the existing features).
>
> However, what I think we should do in the next version (in a few months,
> maybe) is have a new way of exposing the data, as Eduard suggested, which
> has one item per "thing" in the data, and which in all but the dragstart
> and drop events only exposes the type information.
>
> I've noted this in a comment in the spec.
>
>
> On Sat, 23 Jan 2010, Daniel Cheng wrote:
> > >
> > > Formats are generally given by MIME types, with some values
> > > special-cased for legacy reasons. For the purposes of this API,
> > > however, the format strings are opaque, case-sensitive, strings, and
> > > the empty string is a valid format string.
> >
> > RFC 2616 has this to say about MIME types:
> >
> > > The type, subtype, and parameter attribute names are case-insensitive.
> >
> > IE also ignores case for format strings:
> >
> >      <script>
> >
> >       window.clipboardData.setData('Text', 'FAILURE');
> >
> >       window.clipboardData.setData('tEXT', 'SUCCESS');
> >
> >       alert(window.clipboardData.getData('Text'));
> >
> >     </script>
> >
> > results in an alert saying 'SUCCESS'.
> >
> > Given that, would it make sense to change the spec to make format
> > strings case-insensitive?
>
> Webkit and Firefox are case-sensitive. IE only does "TEXT" and "URL", but
> case-insensitively (at least for Text, I didn't test URL). Chrome is
> case-insensitive for everything.
>
> Tough call. I guess we'll go with just converting everything to lowercase,
> so that it's case-insensitive.
>
> BTW I noticed Chrome includes "Text" and "URL" in the .types list. That's
> incorrect according to the spec.
>
> --
> Ian Hickson               U+1047E                )\._.,--....,'``.    fL
> http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
> Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20100204/232dcc7c/attachment.htm>

Received on Thursday, 4 February 2010 17:46:08 UTC