[whatwg] Drag-and-drop feedback

Daniel Cheng dcheng at google.com
Tue Nov 16 16:05:21 PST 2010


On Tue, Nov 16, 2010 at 14:48, Charles Pritchard <chuck at jumis.com> wrote:
>
>  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.
>>>
>> I'm not sure what this means exactly. Could you elaborate?
>>
>
> I don't think these need to be "converted" by a UA -- the application which
> receives the data does that conversion on its own.
>
> This list of transfer types reminds me of all the redundancy that can take
> place in a data transfer.
>
> A sufficiently large XML content file may be transferred in ~4 different
> file formats
> for compatibility with the destination.
>
> This is a good use case for "promise"-based data callbacks.


Automatic conversion is already implemented for some types (text, URL, and
maybe HTML). It's just not explicitly mentioned in the spec. I'm not sure
how a policy of no conversion would work; the clipboard mechanism/encoding
varies greatly from platform to platform. With no automatic conversion, a
page trying to read text from a drop would have to first sniff the operating
system, choose the appropriate strategy for reading text, and then transcode
the result to a DOMString.

Daniel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20101116/5dadc79e/attachment-0001.htm>


More information about the whatwg mailing list