[whatwg] Drag-and-drop feedback
Daniel Cheng
dcheng at chromium.org
Wed Dec 1 14:52:13 PST 2010
Couple of things I noticed after the changes to the DnD spec:
- event.dataTransfer.types no longer mentions "Text" or "URL". Is this
intentional?
- Does the casing of "Text" and "URL" in the return value of
event.dataTransfer.types matter?
Daniel
On Wed, Nov 17, 2010 at 13:05, Charles Pritchard <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> 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/3e10c8d5/attachment.htm>
More information about the whatwg
mailing list