[whatwg] Drag-and-drop feedback

Mon Mar 29 15:26:32 PDT 2010

I like the DataTransferItems proposal. I had a few questions, but no one
answered, so I'm going to propose some modifications:

DataTransferItems is a mapping of types to data like DataTransfer.
DataTransfer mirrors DataTransferItems, but DataTransfer.getData() will
throw an error if the data is a blob. Maybe a second getData method that can
provide conversion given a text encoding would be useful?

DataTransfer changes:
DataTransfer.addFile(fileData);

dataTransfer.items = DataTransferItems

DataTransferItems.length
  .getItem(type) = DataTransferItem
  .add(stringData, type)
  .add(blobData)
  .add(dataTransferItem)
  .clear()

DataTransferItem.kind = 'string', 'blob'
  .type = MIME type
  .getTextData(function callback (data)) - throws if binary is true
  .getBlob() - returns Blob

The binary property has been folded into the "kind" property.

When interacting with non-DOM apps or pages, some platforms can't easily
convert arbitrary MIME types to native data transfer types for copy/paste or
DnD. For this reason, I think the spec should explicitly list MIME types for
which UAs should handle the conversion to native data transfer types. A
couple that come to mind: text/plain, text/uri-list, text/rtf,
application/rtf, text/html, text/xml, image/png, and image/svg+xml.
UAs can make a best-effort attempt to convert the other types, but it won't
be guaranteed that they will be there for interaction with non-DOM
applications.

Daniel

On Tue, Mar 9, 2010 at 3:03 PM, Daniel Cheng <dcheng at google.com> wrote:

> On Fri, Feb 26, 2010 at 10:56 AM, Dmitry Titov <dimich at google.com> wrote:
>
>> On Mon, Feb 22, 2010 at 6:06 PM, Daniel Cheng <dcheng at google.com> wrote:
>>
>>> Several questions about the proposal:
>>> How does DataTransferItems interact with the original DataTransfer
>>> object? I'm assuming changes in one should be reflected in the other. If
>>> that's the case, what should happen if I do this:
>>> dataTransfer.items.add(fileData);
>>> dataTransfer.getData(mimeTypeForFile);
>>>
>>
>> Unless there is a specific reason to think different, there is only one
>> set of items backing DataTransfer object - today the files and 'other items'
>> are represented separtely, the proposed items list is simply a merged
>> version of the same. In your example you should be able to getData.
>>
>
> Does that mean getData() can return types besides DOMString?
>
>
>>
>>
>>> How come there's no DataTransferItems.get(type) method?
>>>
>>
>> There can be multiple items of that type (dragging several image files).
>> Would it return another items list? What is the use case for this? Also,
>> some items may have empty type (a file with unknown extension).
>>
>
> I think files have always been a special case and should continue to be
> handled that way. I don't think there's any platform pasteboard that
> supports multiple items of one non-file type, so it'd make the most sense to
> make it a 1:1 mapping from types to data.
>
>
>>
>> DataTransferItem provides richer metadata than is available through the
>>> native drag-and-drop interface on most platforms. When dragging data from a
>>> non-DOM application, how do you extrapolate the metadata to fill in the
>>> type/binary fields?
>>>
>>
>> 'type' can be inferred in many cases from file extension, native clipboard
>> format or other means. It can be done w/o content sniffing and disk IO.
>>
>
> Should there be some sort of standard list of mappings that all UAs should
> support wherever possible? What happens if the UA doesn't have a mapping for
> a type?
>
>
>>
>> I understand 'binary' as indicator of whether or not the item can be read
>> as a text string. I'm not sure why item.kind == "string" is not the same. If
>> the intent is to also cover some files that can be read as string and as
>> Blob, then it might be buggy because the only way to establish if the file
>> can be converted into JS string is to actually read the bytes and try to
>> convert to Unicode. There can be invalid character sequences or the encoding
>> info may be missing.
>>
>> Perhaps we should remove 'binary' and assume that items that item.kind ==
>> "string" can use getTextData(callback) to pull the string.
>>
>> On a separate note, I think items.add(dataTransferItem) is not useful w/o
>> a way to create a new DataTransferItem separately from the DataTransferItems
>> list.
>>
>>
>>>
>>> Daniel
>>>
>>>
>>> On Mon, Feb 22, 2010 at 3:51 PM, Ian Hickson <ian at hixie.ch> wrote:
>>>
>>>> On Thu, 4 Feb 2010, Ian Hickson 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.
>>>>
>>>> Some engineers at Google discussed this a bit and came up with the
>>>> following proposal:
>>>>
>>>>   dataTransfer.items = DataTransferItems
>>>>
>>>>    DataTransferItems.length
>>>>                     .getItem(n) = DataTransferItem
>>>>                     .add(stringData, type)
>>>>                     .add(blobData)
>>>>                     .add(fileData)
>>>>                     .add(dataTransferItem)
>>>>                     .clear()
>>>>
>>>>    DataTransferItem.kind = 'string', 'file', 'blob', ...
>>>>                    .type = MIME type
>>>>                    .binary = boolean
>>>>                    .getTextData(function callback (data)) - throws if
>>>> binary is true
>>>>                    .getBlob() - returns File or Blob
>>>>
>>>> When we add promises later, this can easily be extended to support that
>>>> as
>>>> well (basically, just by adding a new add() method for the promise
>>>> case).
>>>>
>>>> I've put this into the comment in the spec, but haven't specced it. If
>>>> any
>>>> browser vendors want to try implementing this or something like it, any
>>>> reports of implementation experience would be very useful. Please prefix
>>>> the "items" attribute with some unique string like "webkitItems" or
>>>> "geckoItems" so that it doesn't clash with the spec when we do add
>>>> something like this!
>>>>
>>>> Cheers,
>>>> --
>>>> 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/20100329/59a0a6a6/attachment-0001.htm>