[whatwg] Drag-and-drop feedback

[Daniel Cheng]

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/20100309/0c65604e/attachment-0002.htm>