[whatwg] Drag-and-drop feedback

[Eduard Pascual]

On Sat, Jan 23, 2010 at 11:30 AM, Ian Hickson <ian at hixie.ch> wrote:
> On Mon, 17 Aug 2009, Jian Li 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.
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?
More formally, add a property of type "DragItemList" that might be
called "DragItems". The "DragItem" type (building brick for
"DragItemList") could provide the data and meta-data for each object
being dragged (that'd be the getData, clearData, and setData methods,
a readonly string "type" and a readonly boolean "isFile").
In principle, that list could actually replace the DataTransfer
object. In order to keep compatibility with existing content, either
of these approaches could work:
1) Actually replace the DataTransfer object with the DragItemList, but
make the DragItemList type implement DataTransfer's interface.
2) Instead of replacing, add the list as a new
field/property/attribute/whatever-you-call-it to the DataTransfer
object.
This approach would solve the issues of dragging multiple files and
the potential drop targets needing to check the metadata (such as the
type); but in addition would seamlessly adapt if in the future a
mechanism of performing a multi-object drag appear. Keeping in mind
how many modern software can already handle "multiple" selections,
that seems a quite near feature.
For example, in some word processors it's possible to hold the Ctrl
key while dragging the mouse over the text to select additional text
fragments: when such a "split" selection is dragged or sent to the
clipboard, the text fragments are typically concatenated; but if the
drop or paste target is any kind of list, it would be reasonable (and
in some cases a significant upgrade in usefulness) to import the
fragments as separate entries for the list. As long as the drag (or
cut/copy) source provides some metadata to identify the boundaries of
each fragment, this functionality enhancement would be quite easy to
implement (currently, it is impossible on most contexts).

Anyway, that's just an idea.
BTW, all the type and member names used in the proposal are arbitrary
and can be changing for anything more convenient. The only purpose of
those names was to describe what they represent.

Regards,
Eduard Pascual