[whatwg] Drag-and-drop feedback

On 12/1/2010 2:52 PM, Daniel Cheng wrote:
> Couple of things I noticed after the changes to the DnD spec:
> - event.dataTransfer.types no longer mentions "Text" or "URL". Is this 
> intentional?
They're covered in implementation:
http://www.whatwg.org/specs/web-apps/current-work/multipage/dnd.html#datatransfer
     If format equals "text", change it to "text/plain".
     If format equals "url", change it to "text/uri-list".
     Let format be the first argument, converted to ASCII lowercase
> - Does the casing of "Text" and "URL" in the return value of 
> event.dataTransfer.types matter?
It shouldn't, they are converted to lowercase.

>
> Daniel
>
> On Wed, Nov 17, 2010 at 13:05, Charles Pritchard <chuck at jumis.com 
> <mailto:chuck at jumis.com>> wrote:
>
>     On 11/16/2010 4:05 PM, Daniel Cheng wrote:
>>     On Tue, Nov 16, 2010 at 14:48, Charles Pritchard <chuck at jumis.com
>>     <mailto: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 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
>
>     Sorry, I completely misunderstood this one. I thought you were
>     referring to operations from the browser to the desktop.
>
>     The UA could handle conversion to image/png. It's low-hanging fruit.
>
>     Conversion from complex formats into markup is something that
>     should be handled by the non-DOM app, not the UA.
>
>     Lacking decent markup conversion, a FileList is fine. I don't have
>     to "sniff" the operating system,
>     I just have to be determined on what mime types I'm going to support.
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20101201/c21f324f/attachment-0001.htm>

Received on Wednesday, 1 December 2010 17:38:16 UTC